1. Get set up

Get a sandbox key

Access is by invitation: we send it to your email. Accept it, sign in at the dashboard, and set up your company. The sandbox opens the moment set-up completes. On the dashboard's API keys page, in sandbox, create a key. Its secret is shown once: we store only a hash, so copy it straight into your secret store. You rotate and revoke keys on the same page.

Sandbox keys are prefixed sk_test_. Live keys are prefixed sk_live_.

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

A key must match its host. An sk_test_ key against api.rasto.co is rejected with 401 environment_mismatch rather than operating on the wrong data. See Environments.

The two headers

Every request carries Api-Key. Every POST /api/* also carries a unique Idempotency-Key.

# GET: one header
curl -s $BASE/api/customers -H "Api-Key: $KEY" | jq .

# POST: two headers, plus a content type
curl -s $BASE/api/webhooks \
  -H "Api-Key: $KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://yourapp.example/rasto/webhook"}' | jq .

Mint a fresh UUID for every new request, and reuse one only to retry that exact request. Keys are global per environment, so reusing one on a different endpoint fails loudly with 422 idempotency_key_reused. That is deliberate: it catches key-management bugs instead of silently replaying an unrelated response. See Idempotency.

Your first call

curl -s $BASE/api/corridors -H "Api-Key: $KEY" | jq .

{
  "data": [
    {
      "object": "corridor",
      "service": "onramp",
      "source": {"currency": "usd", "payment_rail": "ach"},
      "target": {"asset": "usdc", "chain": "solana", "network": "testnet"},
      "min_amount": "1",
      "max_amount": "1000000",
      "fees": {
        "bps": "30",
        "spread_bps": "0",
        "min": "0.3",
        "collection": "monthly"
      },
      "estimated_settlement": "instant"
    }
  ],
  "has_more": false,
  "next_cursor": null
}

GET /api/corridors needs no setup, and it is the endpoint your integration reads instead of hard-coding which assets, chains, and rails exist. A new corridor appears here the moment it is enabled for your account. network reads testnet in sandbox and mainnet in live, while chain is the same in both.

Log the request id

Every response carries a request-id header, echoed inside error envelopes as request_id:

curl -si $BASE/api/corridors -H "Api-Key: $KEY" | grep -i '^request-id'

Store it in your logs from day one. Support uses it to find the exact request, including the detail of any failure behind the API that the response does not carry.

What refuses a valid key

Your account standing is checked on every call. Sandbox opens as soon as your partner account exists. Live opens when the dashboard's onboarding checklist is done: your executed Partner Terms on record (we record them), your company's acceptance of our terms, its KYB approved by our team, and your live wallet keys registered and activated. Until then live keys return 403. For the codes and their retry classes, see Errors and Authentication.

Next

Onboard a customer.