1. Get set up

Get a sandbox key

Sign up on the dashboard, or ask your Rasto contact to provision your partner account. Keys are shown once: we store only a hash, so copy it straight into your secret store.

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": {"asset": "usd", "rail": "ach"},
      "target": {"asset": "usdc", "chain": "solana"},
      "min_amount": "1",
      "max_amount": "1000000",
      "fees": {
        "bps": "30",
        "spread_bps": "0",
        "min": "0.30",
        "collection": "monthly"
      },
      "estimated_settlement": "instant"
    }
  ]
}

GET /api/corridors is the right first call for two reasons. It needs no setup, and it is the endpoint your integration should read instead of hard-coding which assets, chains, and rails exist. Corridors are account-scoped configuration, and a new one appears here the moment it is enabled for you.

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. It is the fastest path through support, because it finds the exact request, including the original wording of any downstream failure, which never reaches the API response.

What refuses a valid key

Beyond a bad key, your account standing is enforced on every call. In sandbox these rarely fire, but in live they gate access until your own onboarding finishes:

Full list: Authentication.

Next

Onboard a customer.