Frequently asked questions

Keep them. A green build tells you those checks passed. We focus on agreed rules under controlled failures: what happens when a job retries, a response arrives late, or work overlaps? The receipt shows the behavior we observed, rather than a claim that everything works.

Use the free engine today to check supported integrations against controlled provider twins. For your team’s services, jobs, database changes, and other systems, we build a verification pilot around the behavior that matters to you. We agree on the environment and acceptance checks together.

It’s a rule that must stay true. A payment retry must not send two receipts. A database change must preserve who owns each record. Your team knows the requirement; we work with you to turn it into a check with an observable result.

We start in an isolated test environment and agree on what the test can affect. Integration runs use temporary twin credentials. We don’t need live billing enabled to test receipt behavior, and temporary test credentials should be removed when testing is finished.

It shows what passed, what failed, and what could not be checked for the recorded run. Results apply to the tested version, scenarios, and observation windows. Missing evidence stays unverified. A passing run is not a guarantee that every production failure is covered.

Start with a change you’re worried about: a PR, a query, a job, or a service. Tell us what must keep working. We’ll agree on a small test scope, the environment, and the evidence needed to judge it. You can also try the free integration engine through MCP today.

Connect the MCP server in your client, then ask the agent to test the integration with FetchSandbox. Check the tool activity to see whether it actually called the connector. Agents decide which tools to use; a prompt alone does not guarantee a verification run.

Follow the setup guide for your client.

Open the diagnostic and timeline. First check whether the test reached your app, whether the app used this run’s twin settings, and whether the required fault was observed. Fix that specific blocker before starting another run. Missing observations cannot count as a pass.

Shared receipts show sanitized evidence. Credentials and sensitive application data stay hidden. Available details depend on the run and access permissions; a public link is not a promise of an unrestricted trace.

Use the bindings for the active run. If the session has expired or ended, start a fresh session and update the temporary settings together. Remove them after testing. Don’t mix a new webhook signing secret with an old app configuration.