Verification and common problems - REST API

A controlled test event

curl -X POST https://dockray.io/api/v1/PROJECT_TOKEN/project \
  -H 'Authorization: Bearer PROJECT_PRIVATE_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"exception":{"values":[{"type":"RuntimeException","value":"DockRay control message"}]}}'

A 200 {"success": true} response means the event was recorded. Check the panel under Errors for the project the token points at.

Common problems

401 instead of a recorded event

No key was present in any of the three places - the URL, the form field or the Authorization header. That is the only cause of a 401; the code says nothing about whether the key would have been valid.

404 despite a correct-looking address

A key is present but does not match the project in the URL: it was revoked, it belongs to another project, or the project is disabled in the panel. The response is identical when the token in the URL does not exist at all - that is intentional, so as not to reveal which projects are actually in the database.

200 {"success": false} mistaken for success

This response has two independent causes: the monthly error quota is used up (see below), or the body is missing a required field - exception.values[0].type and .value for an error, a non-empty contexts.trace.data for a transaction. Check the shape of the payload before suspecting the quota.

A gzip-compressed body loses the key

When you send a body with a Content-Encoding: gzip header, a form field carrying the key inside that body is never read - the parser reads the compressed stream straight as JSON, it does not decompress it looking for form fields. Move the key to the URL or to the Authorization header.

A transaction comes back with {"success": false}

Most often contexts.trace.data is missing or empty - it is the only required field of a transaction report.

One error splits into many entries

The fingerprint is computed from type and value. A record identifier pasted into the message text splits one error into a thousand rows - move it into the request context or the stack trace instead.

Requests end in a 429

That is the per-minute request limit per project token (1200 by default), independent of the monthly error quota - it usually means a looping client or retries sent without backing off.

The panel answers 200 but there is no event

A 200 {"success": false} response means the account has used up its monthly error quota. The integration does not treat that as a failure - and rightly so. You can see the quota on the account dashboard; until the end of the month it is counted from recorded usage, so deleting errors does not reset it.

Still not working

Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.