Check a chat integration before customers use it

Section: DOC-DX-local-tooling-testing#test-your-integration.

Before enabling your assistant for customers, verify that it completes the task you promise and recovers when a request or tool call is interrupted. This recipe starts with a working chat integration and adds the tests that catch duplicate actions, lost tool results and regressions.

Before you start: complete the chat quickstart, then arrange a separately provisioned test account with your Travila operator. Use controlled data, recipients and finite spending limits. The current public API has no separate test projects or test keys; model calls can cost money and tools can act in real external accounts.

First run one ordinary conversation through your application and save the conversation, run and result identities. The later checks compare actual outcomes with that baseline. Run the tool and scheduling checks only if your application uses those capabilities.

Verify a connected tool before asking the assistant to use it

Section: DOC-DX-local-tooling-testing#2-call-a-tool-in-isolation.

Choose a read-only tool your test account is allowed to use. Discover its current definition, select the intended connected account and prepare arguments from that definition. Call it directly through /api/v1/llm/mcp-call-tool so you can distinguish a connection or argument problem from the assistant choosing the wrong action.

Use the direct-tool recipe and operation reference for the request. Supply argumentsJson as a JSON object, not an encoded string. requestId helps correlate the response; it is not a general deduplication guarantee.

Verify the returned information belongs to your controlled account and matches the known fixture. Then use the same connection in a conversation and check the assistant's result. For memory tools, authorize the explicit user selector and use isolated test memories until your deployment's memory isolation is qualified; the selector is not proof of permission.

Verify that an in-app action returns control to the conversation

Section: DOC-DX-local-tooling-testing#3-exercise-the-client-tool-loop-end-to-end.

If your assistant can navigate your application, configure a controlled conversation with the navigate_to client tool using the client-tool guide. Replace the sample conversation ID below with that conversation. Ask it to open the profile page:

curl -X POST https://api.travila.ai/api/v1/llm/send-message-sync \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "conversationKey": "b81d5345-c1f9-4fb9-b558-a6327c75b842",
  "userMessage": {
    "role": "ROLE_USER",
    "content": [
      {
        "type": "CONTENT_PART_TYPE_TEXT",
        "content": "Navigate to my profile."
      }
    ]
  }
}'

Reference: Send a message and wait for the result · Request fields.

Read the actual response. When it reports AGENT_STATUS_AWAITING_CLIENT_TOOLS, save the call ID, arguments and clientToolCursor. Check that the user may perform the requested navigation, execute it in your test application, and submit the actual result using those returned values:

curl -X POST https://api.travila.ai/api/v1/llm/submit-client-tool-results-sync \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "conversationKey": "b81d5345-c1f9-4fb9-b558-a6327c75b842",
  "clientToolCursor": 1,
  "results": [
    {
      "toolCallId": "call_abc123",
      "toolName": "navigate_to",
      "resultJson": {
        "navigated_to": "/profile"
      }
    }
  ]
}'

Reference: Submit client-side tool results and wait for the next segment · Request fields.

The sample call ID and cursor above are placeholders. Do not report a navigation that did not happen. Check the new status after submission: another tool round needs another result, active work still needs observation, and a terminal result can be success, failure, cancellation or timeout.

The test passes when the requested page opens and the same conversation reaches its expected result with matching call identities. Also drop the connection once and recover the original pending call before deciding whether it still needs execution. See the full recovery workflow.

Client tools wait for your application; they do not appear in the platform approval queue. Your application performs its own permission check before executing them.

Prevent a network retry from repeating the customer’s action

Section: DOC-DX-local-tooling-testing#1-qualify-retries-before-enabling-them.

Interrupt a response after your application submits a controlled action. Keep the original operation identity and inspect its outcome before sending another mutation. Verify the customer's visible result and the number of real effects, such as messages delivered or records changed.

Enable automatic write retries only for an endpoint whose deduplication contract is qualified for your deployment. Test the same scope, operation key and payload twice, including a lost response. Then test a changed payload, another user, expired retention and revoked access. These cases must not reuse another caller's result or silently repeat an effect.

The public API does not provide universal deduplication or a guaranteed 24-hour retry window. Follow the retry contract; where it is unqualified, recover the original operation and require an explicit decision before a new mutation. Equal response bodies alone do not prove that only one action occurred.

Keep good answers from regressing after a change

Section: DOC-DX-local-tooling-testing#4-regression-test-agent-behaviour-with-eval-datasets.

Save a small set of representative customer tasks and their expected results. Include the successful chat turn, the tool interaction and a failure case your application must handle. Run those cases with the current configuration, then again after changing the model, instructions or tools.

Follow datasets and evaluation runs to create the dataset, execute each item in your harness, score its result and record the run. The evaluation API records evidence; recording a run does not execute its items or authorize actions in customer systems.

Compare the actual answers and task outcomes, investigate failures, and retain the run and configuration references with your release decision. Use isolated fixtures and finite spending limits for both versions. A stored evaluation run without executed cases is not evidence that the new assistant works.

Check a scheduled follow-up before enabling recurrence

Section: DOC-DX-local-tooling-testing#5-verify-scheduler-callbacks-locally.

If the application sends a scheduled briefing or reminder, start with a single controlled callback to your test receiver. Verify its signature and claims before allowing the receiver to start work, then reject invalid callbacks and acknowledge an identical valid retry without repeating the work.

Follow the scheduled-agent recipe through to the final notification or conversation result. Confirm the intended recipient receives it once for the intended execution. A successful callback delivery alone does not prove the downstream task finished.

Use the verification guide's published signing-key discovery and rotation procedure; do not copy a single signing key into the receiver. Enable the recurring schedule only after the controlled execution and failure case behave as expected.

Choose a test setup that matches current availability

Section: DOC-DX-local-tooling-testing#not-yet-available.

What you need	Current setup
Keep tests away from customer data	Arrange a separately provisioned account and controlled destinations with your operator. Public test/live modes are not available.
Use development credentials	Use the supported sk_* or pk_* path. There is no separate test-key type.
Select an isolated project	The current public project is default; a different header does not create a project.
Exercise webhook recovery	Use a controlled real event or delivery retry. A synthetic webhook test-event API is not available.

Keep the exact environment, configuration, observed result and remaining failures with your verification record. Report what you ran; do not mark unsupported test cases as passed.

Document ID: DOC-DX-local-tooling-testing. Section identities and revisions.