Giving feedback
Section: DOC-DX-documentation-feedback#feedback-on-travila.
Use feedback to report a problem with your integration, explain a use case the product does not cover, or point out instructions that led to the wrong result. Include what you were trying to do and the documentation section you followed so the report stays connected to that experience.
Product and documentation feedback submission is upcoming and is not yet available.
Report a documentation or product problem
Section: DOC-DX-documentation-feedback#documentation-feedback.
The experience below describes product and documentation feedback. Its submission API and form are not available yet.
Report an unclear instruction, an integration failure or a missing capability against the section that describes the task. The report stays linked to the wording and availability you read, including upcoming sections beside current instructions. You receive a receipt, can follow the status of reports you are permitted to read, and can withdraw an eligible submission.
Identify the section you read
Status: Upcoming — not yet available.
Section: DOC-DX-documentation-feedback#identify-section.
Each section shows its section ID under its heading. Copy that ID or the page URL when preparing your report.
Each documentation page has a stable document ID, and each section has a stable section ID. Together they identify the subject of your feedback. The section keeps that identity when its title changes, it moves to another page location or its planned behavior becomes available. The revision identifies the exact wording you read; it can change while the section ID stays the same.
For example, this section is DOC-DX-documentation-feedback#identify-section. Use the documentation manifest to obtain its canonical link, revision and availability. You do not need a repository path or knowledge of the implementation.
Explain the problem and expected result
Status: Upcoming — not yet available.
Section: DOC-DX-documentation-feedback#describe-feedback.
Include the context needed to understand and reproduce the problem:
- The document and section IDs, canonical link and revision you read.
- Whether the section describes available, preview or upcoming behavior.
- Your task, the result you expected and what happened instead.
- A small relevant example, plus the API or SDK version and deployment when reporting an integration failure.
For example, if a guide tells you how to reconnect to a conversation but your application displays the same reply twice, identify that section and describe the duplicate result. For an upcoming capability, explain the real workflow or constraint that our described solution does not address. A request to an unavailable interface is a feature request context, not evidence that a released API failed.
Keep credentials, unrelated conversations and unnecessary personal data out of the report.
Let your agent report an integration problem
Status: Upcoming — not yet available.
Section: DOC-DX-documentation-feedback#agent-feedback.
Today, an agent can prepare a report for the developer using the section ID, the documentation manifest, and the page’s Markdown copy. The submission interface described below is upcoming.
An authorized agent submits the same section context and receives a receipt for the report. It separates observed failures from statements in the documentation and includes only the context you authorize. Reading a page does not authorize uploading a conversation.
If the response is lost, the agent recovers the original submission instead of filing duplicates. Status remains linked to the original section and revision after the guide changes. Reports from another customer remain private.
Follow the result of your feedback
Status: Upcoming — not yet available.
Section: DOC-DX-documentation-feedback#proposal-feedback-loop.
We use the reported task and expected result to assess a correction or product change. The original section and revision remain attached to the report, so a later rewrite does not erase what you read. Feedback can identify a missing use case, a defect in available behavior or a change needed in an upcoming experience.
Upcoming documentation describes the experience we intend to deliver. A section becomes available after its implementation and release checks; its identity stays the same as its wording and status change. Publishing that description does not set a release date or commit us to every requested adjustment.
Document ID: DOC-DX-documentation-feedback. Section identities and revisions.