Skip to main content
Every failed request returns the same JSON shape, whether it was stopped at authentication or in the middle of filing with KRA. This page lists what you can get back and what to do about it.

Error format

  • code is stable and machine-readable. Branch on it.
  • message is for people. Show it, log it, but do not parse it: the wording can change.
  • Some errors carry extra fields beside them, such as sale, item, errors, creditNoteId or branches. They are listed below.

Status codes

A 404 for an id from another business is deliberate: whether an id exists in someone else’s account is not something you can learn from us. It is never a 403.

Specific codes

These codes tell you more than the status alone. Examples:

Validation messages

A 400 reports the first problem it finds, and names the field, so you fix one thing at a time:
  • traderInvoiceNumber is required
  • lines[0].quantity must be greater than 0
  • saleDate must be a date as YYYY-MM-DD
Numbers must be JSON numbers. A numeric string such as "3500" is refused, because money is never guessed. Dates are YYYY-MM-DD and must be real calendar dates.

Two kinds of failure

KRA or validation refused it

The request was understood and refused because of something in your data: a code that is not on KRA’s list, a missing classification, too little stock. Status 400, 409 or 422. Fix the data, then retry.

It never went through

A network or system problem on the way to KRA: a timeout, a 502, a 500. Nothing about your request was wrong. Retry with the same Idempotency-Key, which is safe.
Retrying a data problem without fixing the value just fails again with the same reason.

Common KRA rejection reasons

When the code is kra_rejected, the message holds KRA’s own reason. These come up often: If you meet a reason that is not listed and cannot tell which kind it is, contact support with the exact reason text.

Troubleshooting checklist

  1. Call GET /v1/me. If it fails, the problem is the key. See Authentication & API keys.
  2. Read error.code, then error.message. The message names the field or the KRA reason.
  3. For a 422 on a sale, read error.sale.error and error.sale.status: the sale still exists.
  4. For a missing scope, check the key’s permissions on the Integrations page.
  5. For a 403 about environments, check that a test key is acting on a sandbox business, or a live key on a production one.
When you contact support@sync2books.com, send the sale or item id, the time of the request and the error body. Never send the key itself.