Testing against Connect safely

The honest position#

A sandbox exists so that a developer can trigger side effects without a real person receiving them. The public surface documented in this section has no side effects to trigger: /api/public/* is read-only, the MCP endpoint exposes documentation tools whose annotations declare readOnlyHint: true and destructiveHint: false, and there is no public write endpoint of any kind.

So the question splits in two. Against the public surface, you are already safe and need nothing extra. Against a workspace — which is not a public developer surface at all — safety comes from the product's own controls rather than from a parallel environment, and this page says which.

What can be exercised safely today#

There is nothing to clean up after any of these, and nothing that can be left in a bad state. That is the useful consequence of a documentation API that touches no workspace: the usual reason to want a sandbox does not arise.

Testing a webhook receiver without deliveries#

1. Write the Event envelope from the AsyncAPI document into a fixture file, with fictional values throughout — ws_example, ev_…, "Acme Traders", someone@example.net.

   Result Your tests own their data, so they run offline and on a laptop.

2. Sign the fixture yourself: HMAC-SHA256 over <timestamp>.<raw body> with a secret your test owns.

   Result You exercise the real verification path rather than a bypass, which is where receivers usually break.

3. Generate the failures deliberately — a stale timestamp, a flipped byte, the wrong secret, a duplicate id, an unknown type.

   Result You learn that the rejections happen, which no volume of successful deliveries would ever tell you.

4. Replay one fixture twice in the same test.

   Result De-duplication on id is proved, and at-least-once delivery stops being a paragraph you read and becomes a case your code handles.

This is a better test than a live delivery would be, because a live delivery only ever shows you the path that works.

If you do have workspace access#

The controls that make a real workspace safe to experiment in are the product's own, and they are stronger than a sandbox because they are the same rules that run in earnest. Set the channel's autonomy to draft_only and Connect writes replies without sending any of them; set ask_before_send and every outbound action waits for a person in Needs You. Both are described on what Connect may do.

Beyond that: keep fictional contacts obviously fictional, remember that a suppression entry is a real record with real consequences, and know that the daily allowance applies to a test send exactly as it applies to a real one. Nothing about an experiment exempts it from metering or from the audit trail.

A separate workspace, if you can have one, is closer to a sandbox than anything this page can offer — the isolation between workspaces is enforced at three independent layers, not by convention.

Questions#

Related#

• Verifying a Connect webhook signature
• Building an agent on Connect safely
• What Connect may do
• Designing a resilient client
• Security and isolation