Sandbox and production

How to move a 0Pools integration from sandbox smoke tests to reviewed production launch.

Sandbox proves your integration behavior. Production proves your account, funding, limits, webhooks, monitoring, and support process are approved.

Sandbox tests

Test	What it proves
Discovery	Keys and entitlement work.
Capabilities	UI can render approved sides/networks/limits.
Indicative quote	Pricing path is reachable.
Firm quote	Expiry and quote lock are handled.
Transact retry	Idempotency prevents duplicate trades.
Status polling	UI can show pending and terminal states.
Webhook handler	Signature verification and dedupe work.
Ledger reconciliation	Finance joins quote/trade/balance/order records.

Production requirements

Area	Requirement
Account	Active organization, approved KYC/KYB, assigned tier.
Keys	Live keys stored server-side.
Pools	Live `allowedPools`, sides, networks, and limits approved.
Funding	Prefunded balance path confirmed if required.
Webhooks	HTTPS endpoint, signing secret, retry/dedupe behavior tested.
Monitoring	Alerts for quote failures, reserved age, webhook failures, returns, ledger mismatches.
Support	Support packet and escalation path documented.

Cutover rules

Do not mix sandbox and live keys.
Store environment on every record.
Start with limited traffic.
Keep firm quote expiry short in UX.
Disable flows if repeated terminal failures appear.
Do not increase limits without review.

Launch checklist

Run the full sandbox smoke test.
Confirm production entitlements.
Confirm funding/balance state.
Confirm webhook delivery.
Confirm support can trace a test order.
Confirm dashboards and alerts.
Enable limited production traffic.
Review first-day reconciliation.

Sandbox scenario matrix

Scenario	Expected behavior
Entitled pool discovery succeeds.	UI shows only approved pools, sides, networks, and limits.
Pool not entitled.	Server blocks the request; UI does not show the pool as usable.
Firm quote expires.	Accept is disabled or rejected; backend requests a new quote.
User double-clicks accept.	One trade is created or the duplicate returns the same idempotent outcome.
Trade stays reserved.	User ledger remains pending and monitoring tracks age.
Trade fails or releases.	Product releases pending state and preserves support ids.
Webhook arrives twice.	Handler dedupes by event id.
Webhook is delayed.	Polling or trusted reads keep the status moving.

Production cutover diagram

The cutover is intentionally staged. A working sandbox call does not prove that live funding, live entitlements, live webhooks, and support operations are ready.

Go-live evidence packet

Before enabling meaningful production volume, collect:

{
  "environment": "live",
  "partner_id": "partner_123",
  "allowed_pools": ["EUR-USDT"],
  "webhook_verified": true,
  "funding_confirmed": true,
  "monitoring_enabled": true,
  "test_quote_id": "pool_quote_live_123",
  "test_trade_id": "pool_trade_live_456",
  "support_runbook": "approved",
  "first_day_reconciliation_contact": "finance_ops"
}

This packet helps product, engineering, support, and finance agree that the integration is ready. It should not include secrets, raw bank details, or private route configuration.

Rollback rules

Pause or disable the live flow when:

Quote failures repeat across normal retry windows.
Reserved trades age beyond the approved support threshold.
Webhook verification fails.
Ledger reconciliation cannot match partner orders to pool trades.
Users can accept quotes after expiry.
The partner balance model is unclear or underfunded.

Rollback should preserve records. Do not delete quote, trade, ledger, webhook, or request-id history to make dashboards look clean.

Sandbox fixture plan

Sandbox should prove integration behavior, not production liquidity availability.

Fixture	Test	Expected outcome
Active test pool	Discovery and firm quote.	Partner stores quote id and expiry.
Expiring quote	Wait past expiry and accept.	Backend rejects and requests fresh quote.
Duplicate accept	Same order accepted twice.	Same trade or controlled idempotency response.
Webhook replay	Same event delivered twice.	One ledger mutation.
Failed trade	Terminal failed event.	User-safe failure and no settled ledger credit.
Returned trade	Terminal returned event.	Return/refund ledger path is visible.

Go-live signoff packet

{
  "partner_id": "partner_01H",
  "production_key_loaded": true,
  "live_discovery_verified": true,
  "small_live_order_completed": true,
  "webhook_signature_verified": true,
  "ledger_close_test_passed": true,
  "rollback_owner": "partner_ops",
  "support_escalation_ready": true
}

Do not switch traffic from sandbox to production with only a successful quote call. Production readiness requires live entitlement, live funding, live webhook verification, monitoring alerts, support macros, and a controlled first-order reconciliation.

Implementation depth

This page is about moving a 0Pools integration from sandbox to production safely. For developers, the durable boundary is simple: your product should depend on environment, key mode, enabled pools, smoke tests, webhook readiness, and reconciliation evidence; it should not depend on deployment flags, internal secrets, and operator runbooks. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A team completes sandbox quote/transact tests and prepares production. They rerun discovery with live keys, verify live pool entitlement, process a controlled small order, and confirm ledger reconciliation before scaling.

Before and after in practice

Before 0Pools	With 0Pools
Sandbox success is treated as production readiness even though live funding, limits, and webhooks differ.	Production launch is evidence-based and environment-specific.
Product teams infer liquidity behavior from provider-specific screens or manual notes.	Product teams branch on 0Pools objects: pool, quote, trade, balance, webhook, and ledger.
Support asks engineering to reconstruct state from logs.	Support starts from request id, quote id, trade id, event id, and ledger id.

System flow

Records to keep

Record	Why it matters	Example
`environment`	Prevents cross-mode confusion.	`live`
`smoke_test_id`	Evidence of tested path.	`smoke_123`
`webhook_verified`	Confirms async path.	`true`
`reconciliation_contact`	Operational contact for first close.	`finance_ops`

A useful implementation stores these records before adding optional analytics. Analytics can be rebuilt from durable state; missing ids usually cannot be reconstructed after a customer-impacting failure.

Example product record

{
  "product_area": "sandbox-production",
  "partner_reference": "partner_order_123",
  "pool_id": "EUR-USDT",
  "quote_id": "pq_test_123",
  "transact_id": "pt_test_456",
  "status": "reserved",
  "request_id": "req_01HZY0POOLS",
  "reconciliation_state": "open"
}

This record is intentionally partner-facing. It references 0Pools objects and your own product ids, but it does not include private liquidity routes, treasury balances, raw provider payloads, or customer secrets.

Failure modes and recovery

Failure mode	Product response
Test key in production	Fail closed and rotate configuration.
Sandbox ids in live ledger	Separate id prefixes and databases.
No live webhook test	Poll until verified, then enable webhook processing.
No rollback rule	Define suspend/disable behavior before launch.

Use-case patterns

Pattern	How 0Pools helps
Go-live checklist	Move deliberately from test to live.
Production readiness	Prove one full movement.
Rollback planning	Know how to pause safely.

Developer checklist

Read runtime discovery and capabilities before rendering enabled actions.
Create firm quotes only when the user is ready to accept the terms.
Execute from your server with an idempotency key.
Treat webhooks and status reads as the source of truth for settlement state.
Reconcile by durable ids first, then by amount and timestamp.
Do not branch product behavior on provider names, route names, reserve balances, or treasury assumptions.