> 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/test-bench.md).

# Test Bench

Test Bench is a set of simulation tools in the Partner Portal that let you exercise your integration end-to-end without needing a real physician or pharmacy involved. Because it reproduces the core events in an Encounter's lifecycle on demand, it's the fastest way to confirm your systems react correctly before any real patient ever reaches them.

## Accessing Test Bench

You can get to Test Bench two ways: through the Partner Portal main menu, by going to **Integration → Resources → Test Bench**, or via a direct link provided during onboarding. Either route lands you in the same set of simulation tools, so use whichever is more convenient.

## What you can simulate

Test Bench lets you trigger the key events a physician or pharmacy would normally cause, on demand:

* **Create Encounter** — start a brand-new sample visit. Pick a **Patient** from your sandbox patients, and optionally attach a file.
* **Get Encounter** — look up an existing sandbox visit by its **Encounter ID** and see everything on file for it — prescriptions, attachments, notes, and more.
* **Change Status** — move a sandbox visit through its lifecycle. Enter the Encounter ID, choose a new **Status** (Assigned, Support, Waiting Patient, Approved, Processing, Completed, or Cancelled), and add a Reason.
* **Add Offering** — simulate an Offering being added to an existing sandbox Encounter.
* **Reassign** — reassign a sandbox visit to a different clinician. Only clinicians set up for sandbox testing appear as options.
* **Submit Prescription** — simulate a physician prescribing an Offering on an Encounter. This moves it to Processing, sends a sample thank-you message to the patient, then automatically finishes by moving it to Completed.
* **Send Message** — simulate an inbound or outbound message on an Encounter's conversation, choosing who it appears to come from (Patient, Clinician, or Support) and which channel it goes to.
* **Create Voucher** — generate a one-time sandbox voucher, the link a new patient would use to start an intake form and set up their profile.

Each of these mirrors an action a real physician takes while managing an Encounter, which means you can confirm your integration handles them correctly — UI updates, webhook consumption, downstream syncs — without ever having to stage a real clinical workflow.

## How it works

Test Bench simulates the *event*, not the underlying clinical action — it doesn't perform a real prescription or a real pharmacy fulfillment. Instead, it exists purely to let you validate that your side of the integration (your app, your webhook receiver, your order-sync logic) reacts the way you expect when these events occur.

## Verifying an Encounter

**Verify Encounter** is a checklist tool that checks whether a sandbox Encounter has everything a clinician would need to review it properly. Paste in a sandbox Encounter ID and it confirms:

* Encounter created
* Encounter assigned
* Patient has a driver's license on file
* Intake form questions were added
* Offerings were added
* Chargeable flag is set

Anything left unchecked tells you what your integration still needs to send before that visit would be review-ready for a real clinical review.

{% hint style="info" %}
Verify Encounter is a separate tool from the **Test Checker** tool available during onboarding on your Integration setup page. Test Checker walks through your live API integration step by step (patient created, encounter created, offering attached, encounter completed); Verify Encounter checks one specific sandbox Encounter you've already created.
{% endhint %}

## Browsing Sandbox Encounters

Use **Sandbox Encounters** to search and browse every test visit you've created, whether through the simulate actions above or your own API integration. Search by Encounter ID and open any result to see its full details — status, offerings, prescriptions, notes, and files. This view is read-only, so it's meant for checking your work rather than creating or deleting anything.

## Recipe: validating your webhook receiver end-to-end

Test Bench is most useful when paired with a **Sandbox** credential and MDI's Testing Webhooks tooling. Together they let you exercise a full delivery cycle before anything touches production:

{% stepper %}
{% step %}
Switch to a Sandbox credential so nothing you do in Test Bench touches live data. See Environments: Sandbox vs. Live.
{% endstep %}

{% step %}
Point your webhook receiver at your Sandbox endpoint and confirm it's listening.
{% endstep %}

{% step %}
In Test Bench, trigger an event — for example, move an Encounter to Completed.
{% endstep %}

{% step %}
Confirm your receiver gets the corresponding webhook, verifies its signature, and processes the payload correctly.
{% endstep %}

{% step %}
Repeat for each event type you depend on (prescription submitted, message sent, offering added, and each status transition) until you've covered your integration's critical paths.
{% endstep %}
{% endstepper %}

Working through this sequence gives you a repeatable way to confirm your webhook handling is correct before a real Encounter — and a real patient — depends on it.


---

# 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/test-bench.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.