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

# Testing Webhooks

You shouldn't need a real physician, patient, or pharmacy action just to confirm your webhook endpoint is wired up correctly. This page covers how to test webhook delivery in Sandbox and how to generate events on demand.

## Test in Sandbox first

Webhook testing should always happen against your **Sandbox** environment and Sandbox webhook endpoint, using your Sandbox webhook secret for signature verification. See Sandbox vs. Live Environments — Sandbox data is never real and never billed, which makes it the safe place to exercise every event type, including failure and edge cases, as many times as you need.

Before testing event delivery itself, confirm the basics are in place:

* Your endpoint is registered for Sandbox in the Partner Portal and reachable over HTTPS.
* Your endpoint verifies incoming signatures using your Sandbox webhook secret, per Webhook Setup & Signature Verification.
* Your endpoint responds with a 2xx quickly, and defers any heavy processing to run asynchronously.

## Generating events with Test Bench

Rather than performing a full end-to-end flow — submitting a Voucher, waiting for a physician to pick up an Encounter, sending a message from the Clinicians App — you can generate these events directly using the **Test Bench**, found in the Partner Portal under **Integration → Resources → Test Bench**.

Test Bench offers two distinct ways to generate a webhook event, and it's worth knowing which one you're using before you rely on the results:

* **Send Webhooks** fires a raw sample payload for a given event type on demand, with any reference details (like an Encounter ID) you fill in yourself.
* **Simulate Events** drives real Sandbox activity that naturally triggers the event — for example, actually moving an Encounter through a status change — rather than sending a canned payload. Because it exercises your integration against realistic, naturally-generated data instead of a synthetic one-off, it's useful for catching handling bugs that a sample payload alone might not surface.

Between the two, Test Bench can simulate, on demand:

* Submitting a prescription or Offering
* Sending a message
* Adding an Offering to an Encounter
* Moving an Encounter through different statuses in its lifecycle

Each simulated action triggers the same webhook delivery path as the real event would, so it's a reliable way to confirm your endpoint receives, verifies, and processes the payload correctly — without needing a live clinician session. For the full walkthrough of what Test Bench can simulate and how to drive it, see Test Bench.

## What to check on each test event

For every event you generate, confirm the following four things:

{% stepper %}
{% step %}
**Delivery arrived.** Your endpoint received a POST request at all — check your server logs or a request-inspection tool if it didn't. You can also check the Partner Portal's **Webhook Logs** view to confirm the delivery was sent and see the response your endpoint returned.
{% endstep %}

{% step %}
**Signature verification passed.** Recompute the HMAC-SHA256 signature against your Sandbox secret and confirm it matches. If it doesn't, double-check you're verifying against the raw request body and using the Sandbox (not Live) secret.
{% endstep %}

{% step %}
**Your handler behaved correctly.** The right downstream action fired — a notification sent, a record updated — and nothing unintended happened (e.g., a "New Case Message" event from the patient side didn't fire a "doctor replied" notification).
{% endstep %}

{% step %}
**Duplicate handling works.** Manually replay or resend the same test event and confirm your idempotency logic recognizes it as already processed rather than repeating the action. See Retry Policy & Idempotency for the recommended keying pattern.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Because Test Bench events go through the same asynchronous delivery queue as production events, don't expect instant delivery — treat it the same way you would a real webhook and wait for it to arrive rather than assuming it's synchronous with the simulated action.
{% endhint %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mdintegrations.com/partner/troubleshooting/technical-concepts/testing-webhooks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.