Introduction

The conventions every Rasto Business endpoint follows, and where to find each one documented.

The Rasto Business API is REST over HTTPS, with JSON request and response bodies. Every endpoint in the reference follows the conventions on this page.

export BASE=https://sandbox.rasto.co
export KEY=sk_test_...

curl -s $BASE/api/customers -H "Api-Key: $KEY"

The conventions

Convention	Rule	Detail
Authentication	`Api-Key` header on every request	Authentication
Environments	Two hosts, two key prefixes, partitioned data	Environments
Versioning	Optional `Api-Version` header, ISO date. Omitting it pins the oldest supported version	Environments
Idempotency	`Idempotency-Key` required on every `POST /api/*`	Idempotency
Errors	One envelope with a coarse `kind` and a specific `code`. Branch on `code`	Errors
Statuses	Stable vocabulary, and a webhook for each decision you act on	Statuses & Lifecycles
Pagination	Cursor based, `limit` 1 to 100, default 25	Pagination & Filtering
Amounts	Decimal strings. Rates in basis points	Amounts & Precision

Every partner route lives under /api/*. Account-level setup, including API keys and wallet public key registration, happens in the dashboard and is not part of the API. See Authentication.

Naming rules

Discriminator fields are always kind, never type. A customer's kind, a destination's kind, an event's kind.
Money values are decimal strings in the asset's major units, never floats and never smallest-unit integers.
Rates are basis points, never percent. 100 means 1%.
Bank details use native vocabulary: account_number and routing_number for USD. There is no generic account identifier field.
Ids are opaque strings with a stable prefix (cus_, va_, wop_). Do not parse them and do not assume a length: store them in a column of at least 40 characters. The prefix tells you in a log which object an id refers to. For the full list, see Objects & Terminology.

Objects and envelopes

Single resources return the object directly, with an object field naming its kind:

{"id": "cus_033y1FhTOmoW9W2jAuSvQx", "object": "customer", "kind": "individual"}

Lists return a fixed wrapper:

{"data": [], "has_more": false, "next_cursor": null}

Webhook payloads carry the same objects. data.object inside an event has the shape the matching GET returns, as of the moment the event fired, so one model serves both.

Was this page helpful?