Implementation Overview
The whole integration in one page: what you configure once, what you build per customer, and what has to be in place before real money moves.
This page covers the whole integration at a level you can plan against, and links to the page that carries the detail for each step. The Quickstart runs the same path as working code.
1. Configure once
Done once per account, not per customer.
| What | Where | Notes |
|---|---|---|
| Accept the invitation and set up your company | Dashboard | We send the invitation. Set-up opens the sandbox at once |
| Create sandbox API keys | Dashboard, API keys | sk_test_ key against https://sandbox.rasto.co. Shown once |
| Register a webhook endpoint | POST /api/webhooks | Per environment. Sandbox registrations do not carry over to live |
| Complete your own onboarding | Dashboard, onboarding checklist | Partner Terms (we record them), your company's acceptance of our terms, and your own KYB, reviewed by our team |
| Register your two wallet keys | Dashboard, Wallets | Required for live access even if you do not use wallets. We receive public halves only |
| Activate the Primary Signing Key | Dashboard, Wallets | One ceremony, authorized by your cold Recovery Key |
| Create live API keys | Dashboard, API keys | Once the checklist is done |
Live calls return 403 until your Partner Terms, your KYB, and your live
wallet keys are all in place. Rasto staff review your own KYB by hand, which can
take a few business days. While it is in review its details cannot be
changed, and a decline is final: contact us to discuss it.
2. Onboard a customer
Four steps, in this order.
Terms of service
A customer cannot exist without an accepted agreement. Either mint a
hosted link (POST /api/tos_links) and pass the resulting
signed_tos_id, or attest inline with the end customer's real IP.
See Terms of Service.
Create the customer with its intake
POST /api/customers carries identity fields, base64 documents, and
the endorsements you want (endorsements: ["endo_usd"]). Requesting
endo_usd requires email and phone for an individual, or email
for a business, already on the customer or in the same request. Send tax_id too, and
tax_residence_country for an individual: the review needs them. An
individual's name, date of birth, nationality, and address can come
from the documents instead. See Customers.
Submit for verification
POST /api/customers/{customer_id}/verifications. We hold the
documents from the previous step until this first submission. It reads
the customer's documents and, for a business, each controller's, fills
the fields you left empty, and sends the customer to
each requested endorsement's review. Submitting early returns
422 verification_incomplete naming what is outstanding.
Wait for the endorsement
Decisions arrive as endorsement.approved,
endorsement.request_for_information, or endorsement.rejected. A
request for information names bare codes in the missing and issues
buckets. PATCH the customer with the fix: the PATCH resubmits by
itself. See Verification & Endorsements.
Design your UI against the endorsement's status and requirements
buckets, not against verification rounds. The endorsement is the only
public verification reading, and it is the thing that gates features.
3. Move fiat in
Create a virtual account once the currency's endorsement is approved, then show the customer the deposit instructions verbatim.
currencyis required, with no default. The account receives over every rail of that currency unless you name a subset inpayment_rails.- The
destinationis either an externaladdressor one of the customer's heldwallets. - Every step fires a webhook. Nothing needs polling.
- Repointing a destination is a
PATCH, and it is the most security-sensitive call in your integration. Guard it accordingly.
See Virtual Accounts and Money Movement.
4. Hold and send on chain
Wallets need one thing on the customer (at least one approved endorsement) and one thing on you (registered keys).
The verify step is mandatory and automated: your service rebuilds the exact transaction from inputs it already trusts and requires byte equality before the key is touched. Budget real engineering time for it, and read the Signing Guide before you estimate.
The whole create-to-authorize window is 30 seconds, so this path must be automated. Any human approval belongs before the operation is created.
5. Reconcile
| Question | Endpoint |
|---|---|
| What money moved? | GET /api/transactions |
| What does the ledger say a customer holds? | GET /api/balances |
| What does the chain say a wallet holds? | GET /api/wallets/{wallet_id} |
| What happened at a wallet address? | GET /api/wallets/{wallet_id}/history |
| What did we send you? | GET /api/webhook_events |
React to webhooks, and treat the API as the source of truth. See Reconciliation.
6. Rehearse, then go live
Sandbox runs the same API with verification and banking simulated and wallets on testnet, and it delivers real signed webhooks. You drive verification decisions, treasury funding, and fiat deposits yourself, fund wallets from a testnet faucet, and exercise the failure paths before you switch hosts. See Sandbox Testing, then the Going Live checklist.
Switching to live is two changes: the base URL and the key.
What tends to take longest
- Your own onboarding: Partner Terms, your KYB, and your live wallet keys. Start on day one. They gate live access and do not depend on your code.
- The signing service, if you use wallets. The verifier is the piece most teams underestimate.
- Idempotent webhook consumption. Deliveries are at least once, and
ordering is by
sequence, not arrival. - Document capture UX. The requirement buckets tell you exactly what to ask for, but collecting a usable selfie and proof of address from a real person is product work.