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 is the map. It covers an end-to-end 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.
Read this before you scope the work. Two pieces of it (your own onboarding, and wallet key registration) involve people outside your engineering team, so they are the ones worth starting first.
1. Configure once
Done once per account, not per customer.
| What | Where | Notes |
|---|---|---|
| Get sandbox credentials | Dashboard | sk_test_ key against https://sandbox.rasto.co |
| Register a webhook endpoint | POST /api/webhooks | Per environment. Sandbox registrations do not carry over to live |
| Complete your own onboarding | Your Rasto contact | Partner terms plus your own KYB. Live calls refuse until both are done |
| Register your two wallet keys | POST /dashboard/partner/wallet_keys | Only if you use wallets. Public halves only |
| Activate the Primary Signing Key | POST /dashboard/partner/wallet_keys/activation | One ceremony, authorized by your cold Recovery Key |
Your own KYB runs through the same verification pipeline your customers use: your organization is registered as its own business customer, and its approval is what opens live access.
2. Onboard a customer
Four calls, in this order. Nothing about the order is optional.
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, phone, and the two economic_profile
tax fields in the same request. See Customers.
Submit for verification
POST /api/customers/{id}/verifications/submit. Documents sent in the
previous step are staged, not submitted: this is the only call that
starts a 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 and submit again. See
Verification & Endorsements.
Design your UI against the endorsement's status and requirements
buckets, not against verification rounds. The endorsement is the only
public KYC 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.
currencyandrailare both required. There is no default.- 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 three things on the customer (approved verification, at least one approved endorsement) and one thing on you (registered keys).
The verify step is not optional and it is not review-by-eye: 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/{id} |
| What happened at a wallet address? | GET /api/wallets/{id}/history |
| What did we send you? | GET /api/webhook_events |
Webhooks tell you when something happened. The API tells you what is true. A production integration uses both and rebuilds nothing from its own event replay. See Reconciliation.
6. Rehearse, then go live
Sandbox is the full product with everything behind the API simulated, including real signed webhook deliveries. Drive verification decisions, treasury funding, fiat deposits, and wallet deposits yourself, and exercise the failure paths before you switch hosts. See Sandbox Testing, then the Going Live checklist.
Switching to production is two changes: the base URL and the key.
What tends to take longest
- Your own KYB and partner terms. Start on day one; they gate live access and they 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.