Skip to main content

Try a chat request in Postman

Section: DOC-DX-local-tooling-development#set-up-your-development-environment.

Before wiring chat into your application, send one conversation request from Postman and inspect the answer. This gives you a working request to compare with your application's request when authentication or response handling goes wrong.

Before you start: obtain an account, the supported API origin and credentials from your administrator. Use a controlled application user and message. Current requests can invoke paid models or real tools; there is no public sandbox or test-key type. Follow testing setup for an isolated account and controlled destinations.

Import the requests for the chat workflow​

Section: DOC-DX-local-tooling-development#postman-collection.

Import both files into Postman:

Select the Travila Platform environment. Follow the quickstart to choose the conversation creation, message and state requests in order. You do not need to run every operation in the collection.

The collection is generated from the same OpenAPI specs as the reference. Its generated bodies are starting points, not working test fixtures. Replace placeholders using the quickstart and the selected operation's schema; a generated request does not establish that a route is enabled for your deployment.

Point Postman at your account​

Section: DOC-DX-local-tooling-development#base-url.

Set the environment's baseUrl to the API origin supplied for your account. For the hosted API, use https://api.travila.ai.

Keep the origin and credentials for the same account together. The collection supplies each operation's path and JSON request method. For exact paths or a self-written HTTP client, use the API reference.

Identify the application and signed-in user​

Section: DOC-DX-local-tooling-development#required-headers.

For this backend test, set apiKey to the secret key and onBehalfOf to your controlled application user's ID. The collection configures authentication headers once, and its requests inherit them. Keep the key out of shared exports and screenshots.

If you are instead testing the browser/mobile authentication path, use a publishable key and set jwt to the signed-in user's token. Follow authentication for the supported identity setup.

A user-scoped request made with a backend key needs X-On-Behalf-Of. An authenticated user_id is required response means the user identity is missing; fix the request context before changing the conversation payload. The current public project is default; changing X-Project-Id does not create a project or a test environment.

Send a message and inspect the completed result​

Section: DOC-DX-local-tooling-development#body-encoding.

  1. Use the quickstart's request body to create a conversation, replacing its example values with your own allowed settings.
  2. Save the returned conversation ID and use it in the message request. Send a controlled message that does not ask a tool to change an external system.
  3. Inspect the returned status and identifiers. Read the conversation state as the quickstart describes to find the result of your message.
  4. Confirm that the answer belongs to the conversation and user you selected. Save the request with placeholders for secrets so you can compare it with your application later.

A successful HTTP response can acknowledge work that is still running. Use generation outcomes to distinguish an answer from pending work, a tool request or a failure. If a response is lost, recover the known operation before resending a message.

When converting the request into application code, follow the JSON contract for field presence, response names and large integer values. The operation's generated schema remains the source for exact fields.

Use the working request to finish your integration​

Section: DOC-DX-local-tooling-development#whats-next.

Run the same flow from your application's backend and compare its user identity, selected conversation and completed result with Postman. Then follow integration testing for interrupted requests and the tools your application uses.

If you prefer to start in code, the HTTP quickstart provides the request sequence. Build with a coding agent shows how to give that task and its exact reference to an agent.

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