Get started

Requests and responses

Form-encoded parameters in, JSON out. The same rules hold for every endpoint.

Requests

Every endpoint under /api/ accepts both GET and POST, and none takes a JSON body. Parameters go in the query string or in an application/x-www-form-urlencoded body; when a name appears in both, the query string wins.

This document declares every input as a query parameter. On POST the same names may be sent form-encoded instead. Prefer POST with a form body: it keeps parameters out of URLs and logs, and it is the only method on which idempotency_key works.

A request on the wire
POST /api/transaction/create HTTP/1.1
Host: anonpay.org
Authorization: Bearer 0e7c3a9f5b1d8e2c4a6f0b3d5e7a9c1f
Content-Type: application/x-www-form-urlencoded

amount=20&currency=usd&allowed_payment_methods=btc%2Cxmr

Responses

Responses are JSON. A successful one carries "status": "success" beside its data, an error carries "status": "error". Branch on the HTTP status code rather than on status: /api/user/info, called with your own key, puts your account's status there (active or suspended) instead of success.

X-Request-Id is on every response and repeated in the body of every error. Send your own, 8 to 64 letters, digits and -, to tie a response to your logs, and quote it to support. Every response also carries Cache-Control: no-store.

A successful response201 Created
{
  "status": "success",
  "transaction_id": "9c1f0b7a4e2d8f6a3b5c7d9e1f0a2b4c",
  "private_key": "a3f9d0e1c2b4a6f8e0d2c4b6a8f0e2d4",
  "expires": 1754006400
}

Errors share one shape, described on Errors.