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

# Testing your integration

> Verify authentication, retries, delivery, and AI workflows before enabling production traffic.

Start with local tests and read-only checks. Enable each write workflow after you can identify its destination, observe its result, and clean up the test data.

## Prepare a test workspace

Use a dedicated workspace where possible. Otherwise, label synthetic records clearly, use an address you control, and agree on the production actions you intend to exercise.

<Warning>
  An API key beginning with `pk_test_` still accesses its workspace's data. It does not provide an isolated sandbox. AI calls can consume credits, and sending through a real conversation can contact a real customer.
</Warning>

Create a temporary key with only the required scopes. Keep it in your local environment. For MCP, use OAuth with the appropriate workspace and permissions. Revoke temporary credentials or connections when testing is finished.

## Confirm the connection

For REST, run `GET /me` as shown in [Make your first request](/quickstart), then read a small customer or conversation list. Check the returned workspace ID and scopes. An empty list is a valid result.

For MCP, call `workspace_context` and confirm the workspace and capabilities. Use its exact workspace ID as `expectedWorkspaceId` on tools that require it. Start with a read-only tool call.

## Exercise failures locally

Mock these responses in your integration's tests. Use local fault injection to simulate network failures and throttling.

| Scenario | Expected integration behavior |
| - | - |
| Empty data and multiple cursor pages | Handle the empty case and follow each returned cursor |
| `401` or `403` | Explain the authentication or permission problem; avoid an endless retry loop |
| `429` with `Retry-After` | Delay and reduce concurrency |
| Timeout or retryable `5xx` | Use a bounded retry policy; preserve supported write idempotency |
| Same key with a different request | Surface the conflict; do not substitute a fresh key automatically |
| Duplicate or out-of-order webhook | Deduplicate and avoid rolling state back to an older snapshot |
| Invalid webhook signature | Reject the event before processing it |

## Verify one controlled write

Create a labeled synthetic customer using [Create customer](/api-reference/customers/createCustomer) and a new idempotency key. Repeat the identical request with the same key: the response should replay the same result, with no second customer. Read the customer back, record its ID, and delete that synthetic customer when the check is complete.

Use a fresh key for each new logical test. Keep the serialized request unchanged during a replay test. See [Errors and retries](/guides/errors-and-retries) for key scope, retention, and conflict handling.

## Test the workflows you actually use

| Workflow | Acceptance check |
| - | - |
| Customer and conversation sync | Data appears in the intended workspace; repeated syncs do not create duplicates |
| Message recording | A stored message appears in the conversation without external delivery |
| Reply sending | A single reply reaches a recipient you control; retain its message ID and inspect delivery status |
| Scheduled email | The scheduled time is correct; cancel a separate pending test and verify `canceled` |
| Webhooks | Verify a signed test delivery, inspect delivery history, and replay the event locally without repeating its business action |
| Help Center authoring | The proposal appears for human review; existing published content is not silently replaced |
| Evelin | The requested result is usable, permissions are enforced, and expected credit usage is understood |

Recording a message and sending a message are different operations. Read [Send replies](/guides/send-replies) before testing either. A test-thread reply checks the internal flow; it does not prove provider delivery. A queued reply also does not prove that the recipient received it.

## Finish and record the evidence

Keep the test time, workspace ID, resource IDs, outcome, and request IDs where available. Remove synthetic data where supported, cancel pending test sends, remove temporary webhook subscriptions, and revoke temporary keys or OAuth connections. Exclude secrets from the report.

Proceed through the [production checklist](/developer/production-checklist) when these checks pass.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.