Staging Environment

Zenoo provides a full staging environment for integration testing. Staging mirrors the production API surface, including webhook delivery, but uses mock providers instead of real verification services. You can test every flow, error path, and edge case without consuming production credits or triggering real compliance checks. What staging gives you:

Same API endpoints as production, with a different base URL and separate credentials
Mock providers that return simulated results based on pattern-matched test data
Full webhook delivery with the same event types and payload structure as production
Lower rate limits to prevent accidental resource exhaustion during development

Staging vs production

Staging and production are completely isolated. A staging API key will not work against the production URL, and vice versa. Always ensure your environment configuration matches the target environment.

Aspect	Staging	Production
Base URL	`https://instance.staging.onboardapp.io`	`https://instance.prod.onboardapp.io`
API keys	Separate staging keys	Production keys
Providers	Mock/sandbox providers	Live provider APIs (registry, screening providers)
Webhooks	Full delivery, same event types	Full delivery
Rate limits	50 requests/minute	100-300 requests/minute (varies by endpoint)
Data retention	Periodic purge (30 days)	Full retention per contract
Charges	None	Per-verification pricing

Getting started

Request credentials

During onboarding, Zenoo provides:

A staging API key
A staging project hash
A webhook secret for signature verification

If you do not have these, contact your Zenoo account manager or email support@zenoo.com.

Configure your project

Store your staging credentials separately from production. A common pattern:

.env.staging

ZENOO_BASE_URL=https://instance.staging.onboardapp.io
ZENOO_API_KEY=stg_your_staging_key_here
ZENOO_PROJECT_HASH=abc123def456
ZENOO_WEBHOOK_SECRET=whsec_staging_secret_here

.env.production

ZENOO_BASE_URL=https://instance.prod.onboardapp.io
ZENOO_API_KEY=prod_your_production_key_here
ZENOO_PROJECT_HASH=xyz789ghi012
ZENOO_WEBHOOK_SECRET=whsec_production_secret_here

Make a test call

Point at the staging URL and send a request:

curl -X POST \
  "https://instance.staging.onboardapp.io/api/gateway/execute/{project_hash}/api" \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: stg_your_staging_key_here" \
  -H "X-SYNC-TIMEOUT: 15000" \
  -d '{
    "name": "Test Clean Person",
    "date_of_birth": "1990-01-15",
    "country": "GB",
    "entity_type": "person",
    "categories": ["pep", "sanctions", "adverse_media"]
  }'

You should receive a 200 response with pep_status: "No Hit", sanctions_status: "No Hit", and adverse_media_status: "No Hit".

Mock provider behavior

Staging providers use pattern-matched test names to determine outcomes. The mock system recognizes specific strings in the submitted data and returns corresponding results.

Pattern in name	Result
`Clean`	Pass, no screening hits
`PEPMatch`	Refer, PEP match returned
`SanctionsHit`	Fail, sanctions hit returned
`AdverseMedia`	Refer, adverse media matches
`INVALID999` (registration number)	Fail, company not found in registry
`TEST001` (registration number)	Pass, clean company registry result
`TEST002` (registration number)	Refer, company with screening hits

Names that don’t match any pattern default to a clean pass. Pattern matching is case-insensitive.

Mock results include realistic response structures: match scores, screening provider names, categories, and timestamps. The data looks like a real response, but the values are synthetic.

What mock providers do not do

No real screening against WorldCheck, OFAC, HMT, or any live database
No real company registry lookups
No real document verification or biometric liveness checks
No real phone, email, or address verification

Webhook behavior in staging

Staging delivers webhooks with the same event types and payload structure as production:

verification.completed
screening.completed
journey.abandoned
journey.expired
check.failed

Configure your staging webhook URL during onboarding. For local development, use a tunneling tool:

ngrok http 3000
# Configure webhook URL: https://abc123.ngrok.io/webhooks/zenoo

Webhook signature verification works identically in staging. Use your staging webhook secret.

Limitations

Be aware of the following staging limitations:

Mock providers. Staging results are simulated. They test your integration logic, not the accuracy of real providers. Always validate with at least one real verification in production before going live.
No real screening. PEP, sanctions, and adverse media results are pattern-matched, not sourced from live databases. Do not use staging results for compliance decisions.
Lower rate limits. Staging enforces 50 requests per minute (vs 100-300 in production). This is sufficient for integration testing but not for load testing.
Periodic data purge. Staging data is purged every 30 days. Do not store long-lived references to staging cases or verification results.
No SLA. Staging does not have an uptime SLA. Planned maintenance windows may cause brief unavailability.

Next steps

Test Data — Pre-built payloads for every scenario
Integration Scenarios — End-to-end test scripts
Go-Live Checklist — Pre-production requirements

Reference

Testing & Go-Live

Changelog

Staging Environment

Staging Environment

Staging vs production

Getting started

Mock provider behavior

What mock providers do not do

Webhook behavior in staging

Limitations

Next steps

​Staging Environment

​Staging vs production

​Getting started

​Mock provider behavior

​What mock providers do not do

​Webhook behavior in staging

​Limitations

​Next steps

Staging Environment

Staging vs production

Getting started

Mock provider behavior

What mock providers do not do

Webhook behavior in staging

Limitations

Next steps