Your meetings, over HTTP.

[ Quickstart ]

Three steps, about two minutes.

Everything is read-only, so there is nothing you can break while exploring.

export SCRIBEN_API_KEY="scb_live_…"

$ curl https://public-api.scriben.ai/v1/notes?limit=3 \
    -H "Authorization: Bearer $SCRIBEN_API_KEY"

$ curl https://public-api.scriben.ai/v1/notes/n_a41f9c2b0e17 \
    -H "Authorization: Bearer $SCRIBEN_API_KEY"

const res = await fetch(
  "https://public-api.scriben.ai/v1/notes?limit=3",
  { headers: { Authorization: `Bearer ${process.env.SCRIBEN_API_KEY}` } },
);
if (!res.ok) throw new Error((await res.json()).error.code);

const { data, next_cursor } = await res.json();
// next_cursor is opaque — hand it back verbatim, never parse it.

import os, httpx

r = httpx.get(
    "https://public-api.scriben.ai/v1/notes",
    params={"limit": 3},
    headers={"Authorization": f"Bearer {os.environ['SCRIBEN_API_KEY']}"},
)
r.raise_for_status()
notes = r.json()["data"]

[ Authentication ]

One header.

Keys are never accepted in a query parameter. URLs reach access logs, browser history, referrer headers and error trackers — a credential that leaks by being logged leaks everywhere at once.

[ Conventions ]

The same rules on every endpoint.

Learn them once.

Pagination is cursor-based

Pass limit (1–50) and follow next_cursor until has_more is false. Cursors are opaque — do not construct or parse one. Offsets are computed against a list that changes: record a note between page one and page two and every row shifts, so the caller silently re-reads one item and never sees another. A cursor names where it stopped.

let cursor = null, all = [];
do {
  const url = new URL("https://public-api.scriben.ai/v1/notes");
  url.searchParams.set("limit", 50);
  if (cursor) url.searchParams.set("cursor", cursor);

  const page = await (await fetch(url, { headers })).json();
  all.push(...page.data);
  cursor = page.next_cursor;
} while (cursor);

Errors carry a stable code

Branch on code, never on message — the code is part of the contract, the prose is not. Every error carries a request_id; quote it and we can find the exact request.

{
  "error": {
    "code": "not_found",
    "message": "No note with that ref.",
    "request_id": "req_8f2ad41c9b07"
  }
}

Refs, not database ids

Notes are addressed by an opaque per-account ref such as n_a41f9c2b0e17. The same note has a different ref in a different account, so a ref cannot correlate anything across accounts. A ref issued to someone else returns 404 — the same answer an invented one gets.

Every answer shows its work

as_of is on every response, and reads derived from meetings carry source_notes — the notes behind the answer, so a claim about a person is one you can check rather than one you have to trust.

[ Reference ]

Seven endpoints. All of them read.

The full schema is published as OpenAPI 3.1, which is what the SDKs are generated from.

An ambiguous name is a result, not an error

If two people share a first name, /v1/people returns status: "ambiguous" with candidates and a 200. Blending two people into one confident answer is the failure we refuse to ship — call again with the ref you meant.

[ Clients ]

Generate the client, don't write it.

The schema at docs.scriben.ai/openapi.json is generated from the server's own route table, not maintained beside it — a test fails the build if the two disagree. Point a generator at it and the types are the API's types.

$ npx @hey-api/openapi-ts \
    -i https://docs.scriben.ai/openapi.json \
    -o src/scriben

$ npx @openapitools/openapi-generator-cli generate \
    -i https://docs.scriben.ai/openapi.json \
    -g python -o ./scriben

$ go run github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest \
    -package scriben \
    https://docs.scriben.ai/openapi.json > scriben.go

We do not publish hand-written SDKs, and that is a choice rather than a gap. A generated client is correct the day the schema changes; a hand-written one is correct until somebody forgets. If you would rather not generate anything, seven endpoints and one header is an afternoon's worth of fetch.

[ Versioning ]

How this changes, and how it won't.

The question worth answering before you build on something: what can break you, and what cannot.

[ Boundaries ]

What it deliberately will not do.

An interface to your meeting history is only worth having if its limits are exact.

[ Which surface ]

API or MCP.

They are not competing, and they are not for the same job.