Skip to main content
The AroPay API is a JSON-over-HTTPS API. Every dashboard feature is built on it, so anything you see in the UI can be automated with the same calls.

​
Environments and base URLs

The same API runs in two environments; pick the base URL for the environment your credentials belong to (keys are not shared between them): All paths in this reference are relative to the base URL. Requests and responses are identical in both environments, with one exception: POST /fund (the faucet) is sandbox-only and returns 404 on production, where wallets are funded by real on-chain deposits instead.
Integrate and rehearse against the sandbox, then switch baseUrl (and key) to production. A ready-made Postman workspace with both environments lives in the repository under postman/.

​
Authentication

Protected endpoints accept either credential; the Authorization header wins when both are present:
A handful of sensitive endpoints are session-only and return 403 session_required when called with an API key: password change, TOTP and passkey management, key create/revoke, and wallet export. Each is labeled in its endpoint page. Background in Authentication.

​
The response envelope

Every endpoint (except the flat Sandbox probes) wraps its result:
Branch on HTTP status for class of failure and on error.code for specifics; the full catalog is in Errors.

​
Conventions

POST/PATCH/DELETE requests with bodies require Content-Type: application/json; anything else is rejected with 415 unsupported_media_type. (This doubles as CSRF protection.)
Human units, string-typed: "125.50" means 125.5 tokens. No wei, no base units, no floats. The one exception: GET /gas additionally reports wei strings for precision-sensitive tooling.
Wallets, transactions, keys, and passkeys use cuid-style IDs. IDs from another account read as 404 not_found; ownership is enforced on every access.
e.g. "2026-08-13T09:30:00.000Z".
GET /transactions takes page (default 1) and pageSize (default 20, max 100) and returns items, page, pageSize, total.
/fund, /mint, /transfer, /redeem validate the request, record the transaction, and return 201 immediately with the transaction in status QUEUED (txHash: null). A background worker then submits it to the chain (PENDING, txHash set) and tracks it to a terminal state. Poll GET /transactions/{id} until status is CONFIRMED, SETTLED, or FAILED; reads are plain database reads and never block on the chain. Execution failures surface as status: "FAILED" with error and errorCode on the transaction, not as an HTTP error on the POST. See Transactions.

​
Rate limits

30 writes and 120 reads per minute per principal; 10 login attempts per 15 minutes per IP. Exceeding a limit returns 429 rate_limited. Details and patterns in Rate limits.

​
Sandbox endpoints

GET /sandbox (status probe) and POST /sandbox (JSON echo) are unauthenticated connectivity checks with a flat response shape (no data envelope):
Use them to verify connectivity and JSON handling before wiring auth.

​
Try it here

Every endpoint page in this reference has an interactive playground: select the server (production or sandbox), authenticate with the matching aro_sk_… key, and requests run against the live environment. Prefer the sandbox while exploring; production calls move real funds. A good first call is GET /auth/session (under Auth in the sidebar): it echoes back who you are and which credential authenticated.