Skip to main content
All endpoints share the same base URL and API key authentication:
Use the playground on any endpoint page to make real requests from your browser — plug in your API key from the API settings page.

​
Headers on every request

Two headers apply to every endpoint, so the endpoint pages don’t repeat them. Authorization (required) — your API key, sent bare:
Bearer <your_api_key> and Token <your_api_key> are accepted too. See Authentication for keys, workspaces, and failures. Happyscribe-Version (optional) — serve this request as the API was on a given date:
Any ISO date works: it resolves to the newest version on or before it. The header applies to that one request and never changes your key’s pin. Leave it out and your key’s pinned version serves the request. See Versioning.

​
How the API is organized

In the order you meet them while integrating: Start with What you build.

​
Conventions

  • JSON everywhere — send request bodies as JSON with Content-Type: application/json; responses are JSON. A JSON body that arrives with a missing or wrong Content-Type (say text/plain from fetch, or the form type curl -d defaults to) is parsed as JSON anyway. Form-encoded bodies work too. The exception is POST /files, which takes multipart/form-data.
  • Trailing slashes are fine — /bots and /bots/ are the same endpoint. Neither redirects.
  • Pagination — list endpoints return { "object": "list", "data", "has_more", "_links" }. Set the page size with limit (1 to 100, default 25) and follow _links.next.url, absent on the last page, as it is; don’t build cursors. page and per_page are refused with a 400.
  • Webhooks over polling — meetings and bots change asynchronously; follow them with Webhooks.
  • Signed URLs expire — download and media links are short-lived unless their field says otherwise; fetch them fresh.
  • API history — additions and migrations live in the Changelog, not as deprecated clutter in the sidebar.