Configuration - REST API
On this page Responses
Responses
| Response | Meaning |
|---|---|
200 {"success": true} | the event was recorded |
200 {"success": false} | the account has used up its monthly error quota or the body was missing a required field - the two look the same from outside |
401 {"message": "Unauthenticated."} | the request carried no key in any of the three places |
404 {"message": "Project not found."} | the key does not match the project in the URL, the project is disabled, or the project genuinely does not exist |
A 404 deliberately does not say which of the three it was - the response is not meant to reveal whether a given project token exists at all.
Error grouping
The panel groups events by the fingerprint sha256(project token + type + value) and keeps one row per error per day, with an occurrence counter. That is why type and value need to stay stable across calls for the same error: an order number or a user identifier pasted into value splits one error into a thousand separate rows. Keep the variable part in context - the request URL, the user data or the stack frames - not in the message text.
Transaction names
The transaction field should carry the route pattern, such as GET /orders/{order}, not GET /orders/8123. Otherwise the transaction list in the panel splits into as many rows as there were concrete identifiers.
Rate limiting
Ingest allows 1200 requests per minute per project token (thor.ingest.throttle_per_minute) - a safety valve against a looping client, not a business quota. It is independent of the monthly error quota: going over it ends in a 429, not a 200 {"success": false}. Requests also have a body-size ceiling, 2 MB by default.
Data you should not send
Unlike DockRay's own libraries, the REST API does not filter anything itself - your integration decides what goes into request.headers and the user fields. Do not send Authorization, Cookie or any other header carrying a secret. Only attach an IP address, e-mail address or username when you genuinely need it for diagnosis - it is personal data, not technical metadata.
Protecting the private key
The private key is a project secret, not an identifier. Keep it in environment variables, in a secrets manager or in the server configuration - never in the repository, in logs, in a screenshot or in code sent to the browser. One project can hold many keys, so production and staging should each get their own: either can be revoked on its own without interrupting the others. A suspicion that a key leaked is reason enough to revoke it and generate a new one.