Build on Orchory, as a human or an agent

Keys are created by the project owner in the app. Open the project, go to the Settings tab, and in the API access card name the key (for example Selma) and press Create key. The key is shown once, starts with orch_, and binds to that one project. Revoke it from the same card at any time; a revoked key stops working immediately.

Get a free API key →

Send the key as a bearer token on every request. A missing, unknown, or revoked key returns 401 with a JSON body. The key identifies both the caller and the project, so no project id is sent in the URL.

Authorization: Bearer orch_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Base path: /api/v1. Four endpoints:

The build-prompt endpoint re-checks the project's plan entitlement, so a project without it gets the same 403 the UI would show, now with an upgrade_url in the body so an agent can hand its human a paylink.

# Add a seed cluster
curl -sS https://orchory.com/api/v1/seed-clusters \
  -H "Authorization: Bearer $ORCHORY_API_KEY" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{"name": "AI resume builder for nurses", "pageFamily": "landing_page", "hypothesis": "A demand pocket worth owning."}'

# Pull the latest runs
curl -sS https://orchory.com/api/v1/runs \
  -H "Authorization: Bearer $ORCHORY_API_KEY" \
  -H "Accept: application/json"

Prefer to let an agent drive Orchory directly? Point it at the Orchory MCP server over Streamable HTTP at https://orchory.com/api/mcp, authenticated with the same project API key as a bearer token. It exposes the v1 actions as MCP tools.

Claude Desktop & Cursor

Add the server to the client's MCP config (mcpServers block):

{
  "mcpServers": {
    "orchory": {
      "type": "http",
      "url": "https://orchory.com/api/mcp",
      "headers": { "Authorization": "Bearer orch_your_key_here" }
    }
  }
}

OpenClaw

Wire it in one line:

openclaw mcp add orchory --url https://orchory.com/api/mcp --transport streamable-http --header "Authorization=Bearer orch_your_key_here"

Copy-paste agent prompt

Once the server is connected, hand your agent something like:

A run that opens a PR unattended has to survive the two gates it will hit — a plan wall and a rate limit — without a human in the loop. Every error is JSON with a stable status, so your agent can branch on it and keep going.

Wire those recoveries into the call itself. This one honours Retry-After on a 429 and surfaces the upgrade_url on a 403 instead of dying:

# Fetch a build prompt, degrading gracefully on the two gates you will hit
resp=$(curl -sS -w '\n%{http_code}' https://orchory.com/api/v1/opportunities/$ID/prompt \
  -H "Authorization: Bearer $ORCHORY_API_KEY" -H "Accept: application/json")
code=$(printf '%s' "$resp" | tail -n1)
body=$(printf '%s' "$resp" | sed '$d')

case "$code" in
  200) echo "$body" | jq -r '.prompt' | your-agent open-pr ;;   # hand off into your repo
  403) echo "Upgrade needed:" $(echo "$body" | jq -r '.upgrade_url') ;;
  429) sleep 5; exec "$0" ;;                                     # respect Retry-After, retry
  *)   echo "Unexpected $code" >&2; exit 1 ;;
esac

Next actions

Once a call returns a build prompt, the handoff into your own engineering workflow is three steps: fetch the prompt for the top opportunity, have your agent open a PR against your repo with tests, and stop at the merge gate for a human. The build-prompt endpoint is the seam — everything before it is Orchory, everything after it is your CI.