Skip to main content

Base URL

api.recurso.dev is a placeholder — substitute the domain where your Recurso instance is deployed. All API examples in this reference use the same placeholder.

OpenAPI Specification

Every Recurso instance serves its own OpenAPI 3.1 spec at /openapi.json (and /openapi.yaml) — no authentication required. The interactive playground in this reference is powered by a vendored copy of the same spec, so you can also point code generators or API clients directly at your running instance:

Postman collection

A ready-to-import Postman collection covering every endpoint (generated from the OpenAPI spec, grouped by resource) lives in the repository under postman/. Import both recurso.postman_collection.json and recurso.postman_environment.json, select the Recurso environment, then set baseUrl (your instance) and bearerToken (an API key from Developers). Every request then authenticates automatically — see postman/README.md for the regenerate command.

Authentication

Authenticate using API keys in the Authorization header:
Keep your API keys secret. Never expose them in client-side code.

API Key Types

Test keys only work with test data and test payment methods.

Request Format

All requests use JSON:

Response Format

Success responses wrap the result in a data envelope:

List Responses

Collections wrap the array the same way — page through with limit/offset (there is no cursor or has_more flag; an empty or short page means you reached the end):

Pagination

Use limit and offset for pagination:
Pass an explicit limit whenever you need the full set — defaults and caps vary across list endpoints.

Errors

Every error — regardless of endpoint or status code — uses the same envelope: an error object with a stable machine-readable code and a human-readable message:
See Errors for the full code taxonomy.

HTTP Status Codes

Rate Limits

Rate limits depend on your Recurso plan:
Self-hosted users can configure their own rate limits with no restrictions. See the Developer Settings guide for configuration options.
Rate limit info in response headers:

Idempotency

All mutating requests (POST, PUT, PATCH, DELETE) accept an Idempotency-Key header to prevent duplicate operations — keys are scoped per tenant, method, and path:
Use UUIDs or your own unique identifiers as idempotency keys.

Versioning

API version in header (optional):
Without version, you get the latest stable API.