Build on Orchory, as a human or an agent

Keys are issued per project to its owner. While the API-access card moves into the /v2 agent's settings, ask us for one from your workspace and we mint it for you. The key is shown once, starts with orch_, and binds to that one project; ask again to revoke it, and a revoked key stops working immediately.

Preview your site free →

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.