Documentation Index

Fetch the complete documentation index at: https://apidocs.scripe.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Conventions

​

Versioning

Scripe-Api-Version: 2026-08-01

• The current version is 2026-08-01 (Phase 2 release).
• Omitted header → we default to the current version. This is fine for exploration but dangerous in production — pin explicitly so the next version cut doesn’t change your responses under you.
• Unknown version → 400 version_unsupported. The error body lists the versions we still accept.
• We accept at least the two most recent versions at any time, with a minimum 90-day overlap when we sunset an old one. Sunset is announced via the Scripe-Deprecation response header before any code change:

Scripe-Deprecation: 2026-08-01; sunset=2026-12-01; replacement=2026-11-01

​

Pagination

​

Request

GET /v1/notes?projectId=proj_abc&limit=50
GET /v1/notes?projectId=proj_abc&limit=50&cursor=<prev next_cursor>

​

Response envelope

{
  "data": [ /* resource objects */ ],
  "pagination": {
    "next_cursor": "eyJjcmVhdGVkQXQiOiIyMDI2L…",
    "has_more": true
  }
}

• next_cursor is null once there are no more rows.
• has_more is the canonical “loop again?” signal. Don’t compare cursor values — they’re opaque and may change shape across versions.
• A cursor is bound to the request’s filter set. Changing projectId, dateFrom, dateTo, status, folderId, etc. mid-loop will likely emit 400 bad_cursor because the keyset reference no longer applies.
• A cursor never expires server-side, but your filters might (e.g. you filter by a dateTo that’s now in the past). Treat 400 bad_cursor as “start the loop over from the beginning” rather than as a bug.

​

Pagination idiom (pseudocode)

let cursor: string | null = null;
while (true) {
  const u = new URL("https://api.scripe.io/v1/notes");
  u.searchParams.set("projectId", projectId);
  u.searchParams.set("limit", "100");
  if (cursor) u.searchParams.set("cursor", cursor);
  const res = await fetch(u, { headers });
  const { data, pagination } = await res.json();
  yield* data;
  if (!pagination.has_more) break;
  cursor = pagination.next_cursor;
}

​

Errors

{
  "error": {
    "code": "key_revoked",
    "message": "This API key has been revoked.",
    "request_id": "req_01J9Z…",
    "docs_url": "https://docs.scripe.io/api/v1/errors#key_revoked"
  }
}

• code is the canonical machine-readable identifier. Stable across releases. Switch on this — never on message or HTTP status alone.
• message is human-readable and may evolve.
• request_id is your handle to correlate with our Sentry span if you open a support ticket. It also matches the X-Request-Id response header.
• docs_url deep-links to a page describing the code, the most likely cause, and a suggested remediation.
• details (optional) carries a code-specific payload. For example, bad_cursor doesn’t include details, but invalid_request may include the offending field.

​

Status code summary

​

Rate limits

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 117
X-RateLimit-Reset: 41

HTTP/1.1 429 Too Many Requests
Retry-After: 17
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 17

​

Survival tips

• Pre-throttle. Watch Remaining and slow yourself down rather than burning the whole budget.
• Respect Retry-After. It’s the smallest safe sleep value; longer is fine.
• Group by workspace, not by key. Adding more keys for the same workspace doesn’t increase your budget.
• Test mode counts. A test key shares the workspace bucket with live keys. CI loops shouldn’t run against production data without a dedicated test workspace.

​

Headers we set on every response

Scripe-Api-Version: 2026-08-01
X-Request-Id: req_01J9Z…
Access-Control-Allow-Origin: *
Cache-Control: no-store        (default; health probes override)

​

Resource IDs

​

Date and time

2026-08-01T14:23:11.000Z

​

CORS

​

Anything else?