> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/developer-guide/guides/verify-an-integration-action.md). # Verify an Integration Action Verify a configured integration action from authorization through target acknowledgement, including rejection, ambiguous delivery, and test cleanup. Use this guide after [First Verified Conversation](/developer-guide/guides/first-verified-conversation.md) to verify work outside the conversation. The example is a synthetic appointment change against a scheduling test system. Your integration owner supplies the target contract and fixture; Concurrence does not define one universal appointment-write payload for every scheduling system. ## Prerequisites Have a configured test service, a test integration and endpoint, credentials limited to synthetic records, and permission to inspect the operation's evidence. Choose one fixture appointment, record its starting value, and document how the target can be read back and restored. The integration owner must verify that the selected endpoint has no production side effects. Decide whether the test uses direct execution or [approval-gated integration writes](/developer-guide/platform-api/integrations/approval-gated-integration-writes.md). Approval policies and connector write-back review are different paths. The [Review Queue](/developer-guide/platform-api/integrations/review-queue.md) is a separately enabled preview; it is not a prerequisite for every integration action.
An authorized direct call proceeds to execution. A policy-gated call waits for the supported approval and continuation path, or stops on rejection. After execution, independently confirm the target; reconcile uncertain outcomes before retrying.

Approval authorizes a supported call. Only destination evidence establishes the external outcome.

## 1. Establish the Contract and Access Use [Integrations](/developer-guide/platform-api/integrations.md) to inspect the configured endpoint and its input schema. Verify that the test service exposes the intended tool and that its principal has the required access. [Tool Testing](/developer-guide/platform-api/functions/tool-testing.md) explains resolution and the separate integration-endpoint test operation. Record the service configuration, integration/endpoint identifiers, synthetic target record, proposed old-to-new change, and external read-back method. A test label or a generic dry-run flag is not a universal guarantee that nothing will be written. ## 2. Test the Action in Isolation Invoke the integration endpoint's dedicated test operation using the fixture payload that matches its schema. Save the returned result and inspect the target record independently. Classify the result as confirmed, rejected, failed, or unresolved. A returned success from a tool can describe request acceptance rather than a committed target change. If the target processes requests asynchronously, use its documented completion/read-back procedure. Do not invent a retry or idempotency contract where the integration does not provide one. ## 3. Exercise the Conversation Path Start a new test conversation with the configured service and request the same bounded change. Inspect the selected tool, its input, the result, and the resulting agent statement through [Conversation detail](/developer-guide/platform-api/conversations.md) with tool-call metadata requested where supported. For an approval-gated call, verify that the target remains unchanged while the write is parked. Review the exact pending payload, record an approval or rejection through the supported decision operation, and exercise the next supported turn. A granted decision alone is not target acknowledgement. Voice approval behavior is not implied by the text/SMS path. ## 4. Prove the Failure Boundary | Case | Evidence required before passing | | --------------------------------- | ---------------------------------------------------------------------------------------------- | | Missing or unauthorized input | The action is refused and the target remains unchanged | | Reviewer rejects a parked write | No external write; the agent communicates the rejection accurately | | Target rejects the request | The actual error is recorded; the agent does not confirm a completed change | | Connection fails after submission | The result remains unresolved until target read-back or reconciliation establishes the outcome | | Successful target change | Read-back confirms the intended record and value; the agent's statement matches that evidence | An approval consumption can precede an interrupted external call. Verify the destination before any manual retry. Repeating a conversation turn is not proof that a target write will be deduplicated. ## 5. Save Evidence and Clean Up Use the [evaluation packet](https://docs.concurrence.com/platform-overview/evaluation-packet) to record each case, configuration, conversation, operation, target acknowledgement, and reviewer decision. Restore the synthetic appointment using the target's supported process, close test conversations, and reconcile any unresolved writes before deleting test evidence. You are ready to extend the workflow when both normal and failure cases have target evidence. Move to [managed SMS testing](/developer-guide/guides/test-managed-sms.md) for channel behavior or [troubleshooting](/developer-guide/guides/troubleshooting.md) when the evidence stops at an intermediate stage. --- # 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.concurrence.com/developer-guide/guides/verify-an-integration-action.md?ask=&goal= ``` `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.