Skip to content

Sandbox

The sandbox is a tenant-isolated test environment that serves synthetic but schema-faithful data, so your engineers can build and validate an Venturi integration without touching production data or real spend. Everything you learn in the sandbox transfers directly: responses carry the same schema, the same interpretation evidence card, and the same error model as production.

What the sandbox gives you

  • Synthetic, schema-faithful data. Attribution records, coverage, budgets, and exports are generated from the platform's synthetic-data capability. The shapes are identical to production — only the underlying data is fabricated.
  • Disposable test credentials. Sandbox API keys and OAuth clients are issued for development and can be thrown away. They are scoped exactly like production credentials, so you exercise the real scope model.
  • A safe place for mutations. Create exports, register webhooks, rotate keys, and adjust budgets freely — nothing affects production or real billing.

Sandbox credentials never authorize against production

A sandbox credential is rejected by production, and a production credential is rejected by the sandbox. There is no path for sandbox traffic to read, write, or bill against real data — the isolation is enforced, not conventional.

Getting sandbox credentials

Your onboarding contact provisions a sandbox tenant on your Venturi instance and issues disposable test credentials. Treat them like any other secret, but know they carry no production authority.

export ARGMIN_TOKEN="<sandbox-token>"

Running against the sandbox

Point your client or SDK at the sandbox base URL your onboarding contact provides. The request and response surface is identical to production:

curl https://<your-venturi-sandbox>/api/v1/attribution?limit=5 \
  -H "Authorization: Bearer $ARGMIN_TOKEN"
{
  "data": [
    {
      "id": "attr_sbx_01HF8...",
      "provider": "anthropic",
      "served_model": "claude-3-5-sonnet",
      "cost_usd": 0.0089,
      "output_state": "attributed",
      "interpretation": {
        "stage_origin": "stage_b",
        "confidence": 0.88,
        "confidence_band": "high",
        "evidence_basis": "service_resolved",
        "model_version": "rail-2025.11",
        "degradation_state": "none",
        "freshness": "fresh",
        "export_eligibility": "eligible"
      }
    }
  ],
  "page": { "next_cursor": "eyJ...", "limit": 5, "has_more": true }
}

Because the interpretation block, output states, confidence semantics, and error codes are the same as production, you can build and verify your handling of real-world cases — high vs. low confidence, degraded serving, export eligibility — entirely in the sandbox.

Testing webhooks

Register a webhook against the sandbox to exercise the full lifecycle — ownership verification, the SSRF egress guard, signed delivery, and retries — without production traffic. The verification handshake and signing work exactly as in production, so the receiver you validate here is the receiver you ship.

curl -X POST https://<your-venturi-sandbox>/api/v1/webhooks \
  -H "Authorization: Bearer $ARGMIN_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://hooks.example.com/venturi-test",
    "events": ["export.completed", "budget.threshold.crossed"]
  }'

See webhooks for verification, signatures, and retry behavior.

Sample apps

Each SDK ships reference sample apps — a chargeback exporter, a webhook receiver, and an anomaly-alert forwarder — that run end-to-end against the sandbox using only published artifacts. They are the fastest way to confirm your environment is wired correctly before you write integration code.

Moving to production

When your integration works against the sandbox, the move to production is a credential and base-URL swap — no code changes:

  1. Obtain production credentials with the least scope your integration needs.
  2. Point the client at your production instance base URL.
  3. Keep idempotency keys and webhook signature verification in place — they behave identically in production.

Build sandbox-first

Develop and test every integration against the sandbox before pointing it at production data. It is the supported, safe path to a working integration — and the schema parity means there are no surprises at cutover.

Next steps

  • REST API — the full request/response contract.
  • SDKs — typed clients and sample apps.
  • Webhooks — event-driven integrations.