Seed data reference
For integration engineers who want to know which customers, accounts, assets and users a new sandbox organisation starts with.
Discover the resources in your assigned sandbox before running examples. The API does not define a universal seed package, so customer references, account references and UUIDs shown in documentation must be replaced with resources from your own organisation.
Inventory the organisation
Use read operations to build a test-fixture manifest. Follow pagination for every list; the first page is not necessarily the complete inventory.
| Resource | API Reference | Record for your tests |
|---|---|---|
| Current identity | GET /api/users/me | The user and tenant context returned by the service. |
| Token contracts | GET /api/contracts | Asset IDs, status, contract addresses and decimals. |
| Customers | GET /api/customers | Customer references and status. |
| Accounts | GET /api/accounts | Account/customer mapping, asset and provisioning status. |
| Users and roles | GET /api/tenants/{id}/users, GET /api/tenants/{id}/roles | Named users and the role assignments needed for each scenario. |
| Approval groups | GET /api/tenants/{id}/groups | Group keys and members used by the test policies. |
| Policies | GET /api/policies | Active policies, templates and versions. |
| Automations | GET /api/automations | Configured scripts, statuses and triggers. |
| Webhooks | GET /api/webhooks | Receiver IDs, event subscriptions and status; keep secrets separately. |
Verify assets and starting balances
An account can transact only after provisioning reaches ACTIVE and the relevant contract and custody setup are ready. Do not infer supported currencies or decimal precision from a sample using GBP. Read the contract and review Amounts, currencies and precision.
Read each test account with GET /api/accounts/{accountRef}/balances and store the returned total, available, locked and asOf values before the run. Do not assume that a new account has a funded starting balance. If a scenario needs funding, agree the setup with the operator and track any mint to confirmation before starting the scenario.
Prepare independent approvers
Approval scenarios need separate named identities for the initiator and approver. Inspect the assigned users and groups; if an additional user is needed, use the agreed administrator invitation process. Do not share one person's token between roles. See Build your own approval inbox.
Keep fixture data outside credentials
Store the discovered resource IDs and initial state in your test harness, alongside the environment and contract version. Store access tokens, webhook secrets and machine credentials in a secret manager. Refresh the fixture manifest after a reset or provisioning change; an old UUID or account reference may no longer identify an available resource.
API Reference
Open an endpoint for request fields, response examples and the interactive API console.
| Operation | Method |
|---|---|
| List contracts | GET |
| List customers | GET |
| List accounts | GET |
| List team members | GET |
| List policies | GET |
Related pages
Updated 5 days ago