With an ERP — API integration

Onboarding in three steps

1. 1 · Keys & sandboxYou receive test and production keys with separate permissions (issue only, fetch only, both).
2. 2 · Field mapping instead of programmingYour export format (CSV, IDoc-like, JSON) is mapped server-side onto the invoice model — including line items. A dry run shows the result before anything is issued.
3. 3 · Test document → release → liveA sandbox document runs through the real validation; if everything fits, you enable the production key. The integration status (keys, mapping, first documents) is available at any time.

Reliability in continuous operation

• Idempotency: the same document number sent twice → one document, no duplicate. Retries after timeouts are safe.
• Honest errors: an invalid document comes back as an error with the concrete rule violations — never as a silent “it’ll be fine.”
• Tenant separation & segments: ERP keys work only for ERP tenants; web accounts have no API access and vice versa.
• Full archive: API documents too are stored unalterably for 8 years in the GoBD archive — your ERP doesn’t have to do that itself.

Security of the machine interface

API keys are stored hashed (plaintext visible only once at creation), carry permissions (issue only, fetch only) and environments (sandbox/production) and can be rotated at any time. Every call is assigned to a tenant and logged; the web interface and the machine API are strictly separate access paths.

Example call

POST /v1/erp/invoices · Authorization: Bearer <API-Key>
{"number":"RE-2026-1042","buyer":{"name":"Kunde GmbH","country":"DE","vat_id":"DE…"},"lines":[{"name":"Seefracht","net_price":2500,"service_type":"intl_transport"}]}
Response: {"status":"VALID","number":"RE-2026-1042", …} — or the precise validation errors.

Frequently asked questions

How the connection works technically

Your system talks to a lean REST API with API-key authentication: it delivers the invoice data as JSON (header, partners, line items, tax and payment details), CoolHanX builds the EN 16931-compliant XRechnung from it, checks it against BR-DE, assigns the gapless number, archives it GoBD-compliant and reports the status back. Issuing is idempotent: a repeated call with the same reference does not create a duplicate invoice.

From the ERP record to the validated e-invoice

1. 1 · Set up the mappingYour field names are mapped once onto the EN 16931 BT — during onboarding with a test run (sandbox) before anything goes live.
2. 2 · Send dataYour ERP calls the API with the invoice record.
3. 3 · Validate & issueCoolHanX validates, numbers, archives — or returns concrete BR-DE codes on errors, without consuming a number.
4. 4 · Status backThe result (VALID/error), the invoice number and the archive reference go back to your system.

Onboarding, sandbox and pricing

For ERP customers there is a sandbox for safely testing the mapping and the issuing before going live. The offer depends on document volume and connection effort — talk to us, we’ll put together a suitable quote rather than a flat-rate plan.

Related topics

Which ERP systems and formats we connect

We connect anything that can export invoice data — our server-side mapping does the format work. Proven paths:

Connectable from any programming language

The interface is a lean REST API with an API key — connectable from Python, PHP, Java, C#, Node.js or directly via curl. You send the invoice data as JSON; CoolHanX builds, validates, numbers, archives and reports the status back. No forced SDK, no proprietary library.

curl -X POST https://…/v1/erp/invoices -H 'Authorization: Bearer <API-Key>' -H 'Content-Type: application/json' -d '{…}'