> For the complete documentation index, see [llms.txt](https://docs.insurgrid.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.insurgrid.com/testing/sandbox.md).

# Sandbox & testing

**What it's for:** a separate staging environment where you build and prove out your entire integration — endpoint, signature verification, de-duplication, file handling — before it ever touches production data. Nothing you do in staging is billed, and no real customer is contacted.

> **New term — sandbox / staging environment:** a copy of the InsurGrid API and webhook delivery system that behaves exactly like production, but is wired to its own URLs, credentials, and test data. It's where "does my code actually work" gets answered safely.

Treat staging as a hard gate: don't add a production URL or switch to production credentials until staging works end to end, from a fired test event through your signature check to your de-dupe logic.

## Staging URLs & credentials

Every topic (`client-submission`, `form-submission`) has **separate URL slots for staging and production**, and separate credentials for each environment:

| Environment    | Endpoint URL                                                   | Credentials                                                      | Use it for                                                                       |
| -------------- | -------------------------------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| **Staging**    | The staging URL you register per topic in the **API section**. | Your **staging** API token and **staging** signing secret.       | Building and testing. Safe to break, redeploy, and re-test as often as you like. |
| **Production** | The production URL you register per topic.                     | Your **production** API token and **production** signing secret. | Real customer data, once staging works.                                          |

Staging and production credentials are **not interchangeable** — a staging signing secret will never validate a production webhook's signature, and vice versa. If your signature check is failing, confirm you're comparing against the secret for the environment the event actually came from.

See [Get access](/get-started/02-get-access.md) for where to add each URL, and [Get your API credentials](/get-started/03-api-credentials.md) for where each secret lives.

## Send a test event

Once your staging URL is saved for a topic, you don't have to wait for a real submission to test your handler.

1. Open the **API section** of your dashboard.
2. Find **Send test event** next to the topic you want to test (`client-submission` or `form-submission`).
3. Fire it. InsurGrid sends a realistic sample payload to your **staging** URL for that topic — the same shape, headers, and `x-signature` a live event would carry.
4. Confirm your server logged it, returned a `2xx`, and (if you've written the check yet) passed signature verification.

Re-run this as many times as you need while you build — there's no limit tied to testing.

## The delivery log & replay

Every delivery attempt to every URL you've registered — staging or production — is recorded in the **delivery log**, in the API section of your dashboard.

For each attempt you'll see:

| Field               | What it tells you                                                                                                                                                                                                   |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Topic & environment | Which event type and which URL (staging/production) it was sent to.                                                                                                                                                 |
| Timestamp           | When InsurGrid attempted delivery.                                                                                                                                                                                  |
| Response status     | The HTTP status your endpoint returned — or `timeout` / `no response` if it never replied.                                                                                                                          |
| Delivery id         | An identifier for each delivery attempt, shown in the log for tracing a specific attempt (not part of the payload body). For de-duping your processing, see [Delivery & de-duplication](/guides/delivery-dedup.md). |

If an attempt failed (non-`2xx`, timeout, or connection error), you can **replay** it from the log — InsurGrid re-sends the exact same payload to your current URL, so you can confirm a fix without waiting for a new real event or firing another test event.

> The delivery log is your first stop whenever "the webhook never arrived" — before you start adding print statements. See [Troubleshooting](/testing/troubleshooting.md).

## Promoting to production

Once a topic's staging flow works end to end — event arrives, signature verifies, duplicates are handled, files are downloaded before they expire — promote it:

1. Deploy your endpoint to its real, publicly reachable HTTPS URL (not a tunnel — see [Expose your local endpoint](/get-started/05-local-development.md) for why tunnels are dev-only).
2. Add that URL as the **production** URL for the topic, in the API section.
3. Switch your server's configuration to your **production** API token and **production** signing secret.
4. Send a small amount of real traffic and watch the delivery log before assuming it's done.

The API and payload shapes are identical between staging and production — nothing about your handler code should need to change, only the URL and credentials it's pointed at.

Run through the [Integration checklist](/testing/integration-checklist.md) before flipping the switch.

## Related

* [Integration checklist](/testing/integration-checklist.md)
* [Troubleshooting: my webhook isn't arriving](/testing/troubleshooting.md)
* [Get access](/get-started/02-get-access.md)
* [Get your API credentials](/get-started/03-api-credentials.md)
* [Delivery & de-duplication](/guides/delivery-dedup.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.insurgrid.com/testing/sandbox.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.