Skip to main content

​
OpenAPI Reference

Blank API v2 is described by a single OpenAPI 3.1.1 document. Every page under this section is generated from it, so the request and response schemas you see here are the schemas the API actually enforces.

​
How it is produced

Zod schemas and route metadata in Blank’s API contract package are the single source of truth. Runtime validation, this OpenAPI document, the SDK’s types, and its response validation are all generated from that one registry, and CI rejects any drift between them. That means:
  • An operation documented here exists at runtime with exactly this shape.
  • A field absent here is absent from the API.
  • Request schemas are strict — an unexpected property is a 422 validation_failed, not a silently ignored field.

​
Using the specification

Generate a client for a language the SDK does not cover:
Other things it is good for: contract-testing your integration, driving a mock server in CI, and diffing releases to spot contract changes before they reach production.
If you are writing TypeScript, use @blankdotbuild/sdk instead of a generated client. It adds runtime response validation, bounded retries, durable idempotency keys, typed Problem Details errors, pagination helpers, and webhook signature verification on top of the same contract.

​
Operations by tag

The document also declares receiveBlankWebhookEvent, the signed CloudEvent that Blank sends to your endpoint. See Webhooks. For a compact index with scopes and rate policies, see the HTTP reference.

​
Trying operations from this reference

Do not paste a production API key into a browser-based request panel. Keys are server-side credentials, and pasting one into any browser page risks leaking it through history, extensions, or shared screens. Use a blank_test_ key against a non-production deployment, or run the equivalent curl from a server shell.