Skip to main content

Testing with sandbox

Every integration should live in sandbox first. This guide explains what sandbox is, what it gives you (test sponsors, test beneficiaries), and what to verify before requesting production credentials.

Sandbox vs production at a glance​

SandboxProduction
Base URLhttps://sandbox.osigu.comhttps://api.osigu.com
CredentialsSandbox client_id / client_secretDifferent client_id / client_secret
SponsorsMock sponsors + shadowed real sponsorsReal sponsors
BeneficiariesSeeded synthetic dataReal people
BillingNot billableBillable
Rate limits50 req/minHigher, per contract
Webhook deliveryTo your sandbox receiverTo your production receiver
PersistenceMay be reset without noticeNever reset

Test fixtures​

Sandbox seeds each new provider with:

  • 1 mock sponsor — usually named sponsor-sandbox or demo-insurer. Accepts all product types, does not require OTP or biometric, resolves synchronously.
  • 1 mock async sponsor — behaves like a real sponsor that evaluates offline. Every request returns PENDING_SPONSOR and emits authorization.created / authorization.rejected after ~30 seconds.
  • ~10 test beneficiaries — mix of active coverage, expired coverage, and family groups. Search inputs are documented in your onboarding welcome email.
  • A test medication catalogue — codes prefixed MED-SBX-*.

If you didn't get an onboarding sheet with the fixture identifiers, email support@osigu.com.

Run each of these in sandbox and confirm your integration handles them before going live.

Happy path​

  • OAuth token acquisition, cached and reused.
  • Beneficiary search → pre-authorization → dispensation.
  • Prescription creation → dispensation.
  • Outpatient claim → complete → settlement batch dispatch.

Sad paths​

  • Beneficiary not found (404).
  • Beneficiary with inactive coverage (200, coverage.active = false).
  • Pre-authorization request with missing indication (PENDING_INDICATION after complete).
  • Rejected authorization (surface rejection_reason).
  • Duplicate dispensation attempt on the same code (409).
  • Rate-limited token endpoint (429).
  • Webhook delivered with tampered signature — your receiver should return 401.
  • Webhook delivered twice — your receiver dedupes on event_id.

Async coverage​

  • Use the mock async sponsor.
  • Confirm your webhook receiver picks up authorization.created and authorization.rejected within ~1 minute of the complete call.
  • Confirm you don't lock in a decision from the synchronous response when the sponsor says PENDING_SPONSOR.

Resetting state​

Sandbox is not guaranteed to persist. Osigu resets sandbox databases:

  • On major release upgrades (a few times a year).
  • On explicit request (email support@osigu.com if your test data got tangled).

Never store sandbox beneficiary_ids / authorization_ids in a production database. Your integration should be able to re-populate any local caches from a fresh sandbox after a reset.

Rate-limit tips​

Sandbox rate limits are stricter than production (50 req/min per client on general endpoints). If you're running load tests:

  • Coordinate with Osigu — the ops team can lift limits temporarily. Give at least 24h notice.
  • Cap concurrent workers — 5–10 is usually plenty for functional testing.
  • Cache tokens — one refresh per 50 minutes, not one per test.

Go-live checklist​

Before requesting production credentials, confirm:

  • All happy-path scenarios pass in sandbox.
  • Sad-path scenarios return the expected error codes and surface them to the user.
  • Webhook receiver verifies signature, dedupes on event_id, returns 2xx within 10s.
  • OAuth token caching avoids the 10/min rate limit on /oauth/token.
  • Retry policy handles 5xx with backoff and gives up after a bounded number of attempts.
  • Sensitive data (OAuth secret, webhook secret) is stored in a secrets manager, not code.
  • Idempotency: replaying a webhook delivery does not create duplicate side effects.
  • Monitoring: dashboards / alerts for token expiration failures, webhook 4xx/5xx, and pipeline stalls.

Email support@osigu.com with your checklist confirmation. Osigu will issue production credentials and configure your webhook subscription for the live environment.