developers

The OnboardHive API

Read your pipeline from your own stack — proposals, engagement, onboarding progress, deal value. REST over HTTPS, JSON in and out, bearer-token auth. Included on Scale and Team.

Authentication

Create a key in Settings → API. The key is shown once, at creation — we only ever store its hash, so there is no way to recover it later. Send it as a bearer token:

curl https://www.onboardhive.com/api/v1/me \
  -H "Authorization: Bearer ohk_your_key_here"

Keys are scoped read or write, and can be revoked instantly. A revoked key stops working on its next request — not at the end of a cache window. If your workspace drops below Scale, every key stops working too.

Endpoints

GET/api/v1/meread

Who this key belongs to and what it can do. Side-effect free — the right call for a client library to make on startup to verify configuration.

{
  "account": { "id": "…", "agency": "Northlight Studio", "plan": "scale" },
  "key": { "scope": "read" }
}
GET/api/v1/clientsread

Your pipeline, newest activity first. Query params: stage (lead, proposal, onboarding, live, archived), assignee, limit (max 100), and cursor.

Pagination is by cursor, not offset. A pipeline changes while you walk it, and offset paging silently skips rows when it does — so a nightly sync would lose clients. Pass the returned nextCursor to get the next page. Archived clients are excluded unless you ask for them by name.

{
  "data": [ { …client… } ],
  "nextCursor": "2026-07-02T00:00:00.000Z",
  "hasMore": true
}
GET/api/v1/clients/:idread

One client, same shape as a list row.

{
  "id": "…",
  "company": "Acme Ltd",
  "contact": { "name": "Ada", "email": "ada@acme.com", "phone": null },
  "stage": "proposal",
  "assignee": { "id": "…", "name": "Priya" },
  "proposal": {
    "status": "sent",
    "versions": 3,
    "liveVersion": { "id": "…", "num": 3, "title": "Retainer", "publishedAt": "…" },
    "awaitingApproval": false,
    "decidedAt": null,
    "value": 12000, "currency": "$", "valueBooked": false
  },
  "onboarding": { "total": 7, "complete": 4, "completedAt": null },
  "engagement": { "opens": 9, "readSeconds": 412, "lastOpenAt": "…" },
  "createdAt": "…", "updatedAt": "…"
}

What the API never returns

Client magic-link tokens, portal passwords, and proposal file bytes are not exposed on any endpoint. A magic link grants portal access to a client's proposal; if it travelled in an API response, a leaked key would leak every client's portal with it. Use the dashboard to share links.

Errors & limits

Every non-2xx response has the same envelope, so you can branch on error.code instead of parsing prose.

{ "error": { "message": "That API key has been revoked.", "code": "unauthenticated" } }
  • unauthenticated (401) — missing, malformed, unknown or revoked key.
  • forbidden / read_only (403) — a read key attempted a write.
  • upgrade (402) — the workspace is no longer on a plan that includes the API.
  • not_found (404) — no such client in this workspace.
  • rate_limited (429) — 2,000 reads or 600 writes per key per hour.

Prefer to be pushed?

The API is for pulling. If you want OnboardHive to tell you when something happens — a proposal opened, a client signed, an onboarding step completed — use outbound webhooks instead (Settings → Integrations). They're signed with the Standard Webhooks scheme and available on every paid plan.

Wire OnboardHive into your stack

API access is included on Scale and Team.

See plans →