API response

What should an API return after e-invoice submission?

⚠ Machine-translated answer, not yet manually reviewed. For the exact wording, see the Slovak original.

Short answer

The response should be machine-readable and include the internal invoice ID, submission-attempt ID, the provider’s transaction ID, current status, timestamp, XML hash and any warnings or errors. For asynchronous submission, it must report that processing is pending rather than incorrectly claiming successful delivery.

ID

Invoice and attempt

Distinguish the document and specific send attempt.

Status

State of play

For example, accepted, queued, failed or delivered by mapping.

Hash

Binding XML

The answer should be linked to the exact content.

Errors

Codes and reports

The error is to be repairable, not mysterious.

Detailed explanation

The worst possible response is simply the text ‘OK’. The ERP system needs data on the basis of which it can save the status, update it later and synchronise it with the webhook. In the event of an error, the API must return a status code, a message for the user and technical details for support.

As set out in the Act

Traceability of the process requires that the submission and subsequent delivery statuses can be traced back to a specific document and attempt.

Practical examples

  • The API returns the status ‘queued’ and the ‘submissionId’ for further tracking.
  • An ‘endpoint-not-found’ error is logged against the document and creates a task for the invoicing clerk.
  • A webhook will later arrive with the same submissionId and a ‘delivered’ status.

Most common mistakes

  • “An HTTP 200 is sufficient.” The HTTP status is neither a business status nor a delivery status for the invoice.
  • “The API can return ‘delivered’ straight away.” Only if the partner has actually confirmed this.
  • “Errors can be free-form text.” You need codes for automated processing.

Conclusion

The API response should be a usable integration and evidence record, not merely an acknowledgement that the HTTP request was accepted.

Legal basis

  • Act No. 222/2004 Coll. on VAT, Section 76a
  • Internal API documentation
  • Partner Delivery Status

Related questions

This is not legal advice. Sources: Act No. 222/2004 Coll. on VAT, Slovak Financial Administration e-invoicing FAQ, OpenPeppol BIS Billing 3.0 and the Slovak e-Invoicing Centre’s internal validation model. Verified on 7 July 2026.