Skip to main content
The Scrip API is a REST API. All requests and responses use JSON. The current version is v1. There are no client libraries yet: every example is plain HTTP, and you can generate a client from the OpenAPI spec or point AI tools at the AI resources.
If you’re new to Scrip, start with the Quickstart to create a program and process your first event, or read Core Concepts for an overview of the data model.

Authentication

Every request requires an API key in the Authorization header:
Keys use the sk_ prefix and have full read/write access to all resources in your organization. You can also pass the key via the X-API-Key header. Create and manage keys from the Scrip dashboard. See the Authentication page for details on key management and rate limits.

Conventions


Idempotency

Events, balance operations (hold, release, forfeit), redemptions, reversals, and transfers accept an idempotency_key field. Use deterministic keys derived from your domain data (order-12345-completed), not random UUIDs. Balance operations (adjust, hold, release, forfeit, and void-hold, for both participants and groups) also accept the standard Idempotency-Key HTTP header as an alternative to the body field:
  • Header only: the header value is used as the idempotency key.
  • Body only: the body value is used (unchanged behavior).
  • Both, equal: treated as one key.
  • Both, different: 400 with reason header_body_mismatch. The API never silently picks one.
Header values must be 1–255 printable ASCII characters. Malformed values are rejected with a 400 whose details carry a reason: empty, too_long, invalid_characters, or multiple_values. On event ingestion endpoints, the idempotency key is carried only by the body field; a well-formed Idempotency-Key header is ignored there, though malformed values are still rejected. Events use the idempotency key as the logical event identity:
  • Reusing the same program_id + idempotency_key returns the same event identity without reprocessing, even if the payload differs.
  • To correct or replace an event, send a new event with a new idempotency key.
Other idempotent operations compare the request payload:
  • Same key + same payload: returns the original response without reprocessing.
  • Same key + different payload: returns 409 Conflict with code idempotency_conflict.
Keys are scoped to program_id. For operations that compare payloads, comparison uses a SHA-256 hash of semantic fields. Cosmetic differences (JSON key order, trailing decimal zeros, whitespace) are normalized before hashing, so they will not trigger a conflict.

Pagination

List endpoints return paginated results using cursor-based pagination:
Pass cursor as a query parameter to fetch the next page. Use limit to control page size (default 50, max 200). Pagination is stable across concurrent modifications. Inserts and deletes between pages do not cause skipped or duplicated results.
Most list endpoints support query parameters for filtering and ordering results. Available parameters vary by endpoint and are documented in each endpoint’s parameter table.

Filtering

Filter by resource status or related IDs:
Time-range filters (from, to) accept RFC 3339 timestamps and filter on the resource’s creation time. from is required when to is provided, and from must be before to.

Sorting

Control result ordering with sort_by and sort_dir:
Each endpoint defines its own set of sortable fields (e.g., created_at, name, order). The default sort is typically created_at descending. Rules default to order ascending. Search uses case-insensitive partial matching. The searched field varies by resource:

Errors

Error responses include a machine-readable code and a human-readable message:
Some errors include a details object with field-level validation information:

Status codes

Error codes

The code field in error responses is a machine-readable string you can match on programmatically. Common codes by category:

Validation (400)

Authentication & authorization (401 / 403)

Not found (404)

Conflict (409)

Business rules (422)


Rate limits

Requests are rate-limited per organization at 10 requests/second with burst to 30. All API keys in the same organization share one rate limit bucket. Every response includes X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. When exceeded, the API returns 429 with a Retry-After header. See Authentication for the full header reference.

Resources

For a complete map of entities and their relationships, see the Data Model.