> This page is for version v6.0 (default).
> For other versions, use one of these documentation indexes:
> - v6.0 (default): https://docs.zip.tax/v-6-0/llms.txt
> - v5.0: https://docs.zip.tax/v-5-0/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.zip.tax/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.zip.tax/_mcp/server.

# Test & monitor

Once you have at least one endpoint configured, you can send a test event and
watch delivery status directly from **Develop > Events**.

## Send a test event

The **Sample payload** card shows the exact JSON that will be delivered, with
**Copy** and **Send test event** buttons.

* **Send test event** POSTs the sample payload to **every** configured endpoint
  and reports how many succeeded (for example, "Delivered to 2 of 2
  endpoints").
* Test-event deliveries are sent with the header
  **`User-Agent: Ziptax-Webhooks/test`** and use a **10-second timeout** per
  endpoint.
* The sample payload and the test delivery reflect your account's
  [Granularity Level](configure#granularity-level): at **Postal code**
  granularity (Enterprise plans) the body includes `postalcodeList`, exactly as
  a real delivery would.
* You need at least one configured endpoint to send a test event.

> **Info**
>
> Test events are signed with the same `X-Signature` header as real deliveries,
> so you can exercise your [signature verification](verify) end to end with the
> **Send test event** button.

## Troubleshoot a failed test

If a test delivery fails, the product surfaces the reason so you can
self-diagnose. Common failure reasons:

| What you see                                          | Likely cause                                                                                                         |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Endpoint did not accept the POST / non-`2xx` response | Your handler returned an error or non-`2xx` status. Return `2xx` to acknowledge.                                     |
| Host could not be resolved                            | The URL's domain does not resolve. Check for typos.                                                                  |
| Connection refused / reset / timed out                | Nothing is listening, or the response took too long. Confirm the service is running and responds within the timeout. |
| TLS certificate error                                 | The HTTPS certificate is invalid, expired, or untrusted.                                                             |

## Delivery status & monitoring

The Events page shows a status overview for your account:

* **Status:** `Delivering` or `Paused`.
  * **Paused** when there are **no endpoints configured** (or the last one was
    removed), **or** when **every event is toggled off** across all endpoints.
  * **Delivering** otherwise.
* **Last delivery:** the time of the most recent delivery across your account's
  endpoints (relative, e.g. "6h ago").
* **Last response code:** the HTTP status returned by that most recent delivery
  (`2xx` = success).

> **Info**
>
> Only the **single most recent** delivery is surfaced. There is no full delivery
> history or log feed in the product today. If you need a durable record of every
> delivery, log deliveries in your own handler as you receive them.

## Next step

#### [Best practices](best-practices)

Patterns for reliable, secure webhook handling.