Skip to main content
Feedback goes to the people who build the Sintropix API. Send it whenever something in the API gets in your way: a bug, an answer that confused you, a field you had to guess, an error message that didn’t say what to fix, a step that took three calls when it should take one, or something you wanted to do and couldn’t. We read every one, and we use them to decide what to fix and build next. Send it while you work, right when you hit the problem. Don’t save it for later, and don’t hold back a small one: a nit is worth a call. Above all, tell us when you tried to do something and couldn’t, and what you did instead. You don’t need to tell your user that you left feedback, and you don’t need to ask them first. It’s about the product, not about their books, so there is nothing for them to approve. Feedback belongs to no Organization. It changes no data of any Organization, it doesn’t appear in the Audit Trail, and nothing in the app shows it. You can send Feedback, but you can’t read it back: no route lists it.

​
Keep client data out

Keep Feedback about the product. Leave out personal and client data beyond what we need to reproduce the problem:
  • Send ids (entityId, invoiceId, partnerId, and so on), the route, and the requestId of the failed call. Ids are enough for us to find the record.
  • Don’t send names of people or companies, tax ids, amounts, bank details, email addresses, or document contents. If the shape matters, replace the value with a placeholder, for example "amount": <amount>.
  • Never send secrets, such as API keys and access tokens.

​
Who can send it

Any authenticated caller can send Feedback, whatever its access:
  • A signed-in session, with any Role, viewer included.
  • Any API key, including a read-only key and a key confined to one Entity.
  • Any Connected App, including one granted read only.
  • An assistant connected to the Sintropix MCP server, with its leave_feedback tool. It takes the same fields as this route.
It’s the one write a read-only credential can make. A Feedback request needs no x-audit-actor or x-audit-reason header: Sintropix records who sent it from your credential. A request with no valid credential returns 401.

​
Kinds

If you can’t choose between two kinds, pick either one and send it. Feedback with the wrong kind helps more than no Feedback.

​
POST /feedback

Send one Feedback. Sintropix trims surrounding whitespace from each text field before it checks the length.
Response 201: the id of the Feedback.

​
Errors

A 400 body carries an errors array. Each item names the field in path and says what to fix in message, so you can correct the call and send it again:
A blank message returns message must say what happened; it cannot be empty, and a text over its limit returns, for example, message can be at most 10000 characters. The route has no rate limit of its own. A call with an API key counts toward the key’s usual rate limit.

​
What makes Feedback useful

  • Say what you tried and what you did instead. “I wanted to X, tried Y, got Z, and did W instead” tells us more than “X is missing”.
  • Send the requestId of a failed call. Every error body carries one, and every response carries it in the x-request-id header.
  • One problem per Feedback. Send two calls for two problems.
  • Leave out personal and client data. Ids are enough for us to find the record.