> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zenoo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Staging Environment

> Dedicated staging environment that mirrors the production API with mock providers for integration testing.

# 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

<Warning>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.</Warning>

| 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

<Steps>
  <Step title="Request credentials">
    During onboarding, Zenoo provides:

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

    <Info>If you do not have these, contact your Zenoo account manager or email [support@zenoo.com](mailto:support@zenoo.com).</Info>
  </Step>

  <Step title="Configure your project">
    Store your staging credentials separately from production. A common pattern:

    ```bash .env.staging theme={null}
    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
    ```

    ```bash .env.production theme={null}
    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
    ```
  </Step>

  <Step title="Make a test call">
    Point at the staging URL and send a request:

    ```bash theme={null}
    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"`.
  </Step>
</Steps>

## 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  |

<Tip>Names that don't match any pattern default to a clean pass. Pattern matching is case-insensitive.</Tip>

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:

```bash theme={null}
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

<Note>
  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.
</Note>

## Next steps

* [Test Data](/testing/test-data) -- Pre-built payloads for every scenario
* [Integration Scenarios](/testing/integration-scenarios) -- End-to-end test scripts
* [Go-Live Checklist](/testing/go-live-checklist) -- Pre-production requirements