Public guide vs sandbox
Mozaca exposes representative API shapes publicly so engineering teams can evaluate the operating model early.
Approved OpenAPI documents, sandbox credentials, SDK access, and test data are issued through controlled access once product, jurisdiction, rail, and compliance scope are aligned.
Sandbox packet
A qualified sandbox review should include enough material for an engineering team to build without guessing at state transitions or event behavior.
| Artifact | Purpose | Status |
|---|---|---|
| OpenAPI spec | Endpoint, schema, auth, and error contract | Issued during review |
| Postman or Bruno collection | Fast endpoint exploration | Issued during review |
| Webhook signing secret | Signature verification and replay tests | Issued during review |
| Seed data | Wallets, accounts, approvals, rails, and events | Issued during review |
| SDKs | Typed helpers for auth, retries, and webhooks | Planned access tier |
Test data
Sandbox data should model the states that break real launches: pending funding, failed rail submission, compliance holds, duplicate idempotency keys, webhook retry, reconciliation exceptions, and reversed transfers.
- Use test phone numbers and rail references only.
- Never upload production identity documents into sandbox unless the agreement explicitly allows it.
- Keep test webhooks pointed at infrastructure your team owns.
Promotion to pilot
Sandbox completion feeds the pilot approval path: operating entity, rail approval, compliance model, support path, monitoring, and evidence exports.
Related docs