Environments
A sandbox to build against and production for real funds. Separate keys for each.
| Environment | API base URL | Origin (for the client and connector) |
|---|---|---|
| Sandbox | https://stagingvault.megtrust.com/api/v1 | https://stagingvault.megtrust.com |
| Production | https://vault.megtrust.com/api/v1 | https://vault.megtrust.com |
The two environments share one API contract and nothing else: workspaces, wallets, destinations, payouts, webhook endpoints and API keys are all separate.
Separate keys per environment
A key registered in the sandbox console does not work in production, and the reverse. Generate a separate keypair for each environment and each integration, and register each public key in that environment's console under Developers → API keys. See Generate keys.
Do not infer sandbox versus production from the Key ID. Confirm the host you are calling.
Base URL versus origin
Endpoint paths in these docs start with /api/v1/. The supplied Node.js client
and the API connector take the origin only — for example
MEGTRUST_BASE_URL=https://stagingvault.megtrust.com — and add /api/v1/... themselves. Do not append
/api/v1 to MEGTRUST_BASE_URL.
Sandbox funds
The sandbox holds test-network assets with no real value. usd_value is still populated there,
priced off the matching main network, so you can build displays against it — but treat it as
indicative everywhere, and never use it for your own limits.
Webhooks and status
Treat GET /api/v1/withdrawals/{id} as the source of truth for a payout, and webhooks as a
notification that something may have changed. An integration that polls for status works in both
environments whether or not a webhook arrives. See Webhooks.
Going live
Build and test end to end in the sandbox first, then repeat a read-only signed call against production with a separate production key. The go-live checklist lists every step.