eRechnung per JSON · gotomaxx Outgoing API

gotomaxx · Outgoing REST API

Mit der gotomaxx eRechnungs API zur eRechnung

Ein strukturiertes JSON‑Objekt hochladen und daraus automatisch eine gültige XRechnung oder ZUGFeRD‑Rechnung erzeugen & versenden lassen.

POST https://post.gotomaxx.com/IhrFirmenname/service/rest/outgoing/json

IhrFirmenname ist nur ein Platzhalter für Ihre eigene PDFMAILER CLOUD. Den genauen Endpunkt entnehmen Sie bitte Ihrer PDFMAILER CLOUD URL.

01Überblick

Sie schicken ein JSON‑Objekt mit den Belegdaten Ihrer Rechnung. Der Dienst validiert die Werte, ergänzt fehlende Angaben (optional) und produziert daraus das eRechnungs‑Format Ihrer Wahl: als PDF/A‑3B mit eingebettetem XML (ZUGFeRD) oder als reines XRechnung‑XML.

Zusätzlich kann derselbe Aufruf das erzeugte Dokument direkt versenden (E‑Mail), archivieren oder Ihnen die Datei nur zum Download zurückgeben. Alles über einen einzigen Request.

Standardformat

Beim JSON‑Upload ist transform: "ZUGFeRD" die Voreinstellung. Für eine XRechnung setzen Sie ausdrücklich transform: "XRechnung".

02Voraussetzungen

Basis‑URL = deine eigene PDFMAILER CLOUD

In der Beispiel‑URL https://post.gotomaxx.com/IhrFirmenname steht IhrFirmenname nur als Platzhalter für den Namen Ihrer eigenen PDFMAILER‑CLOUD (Portal). Verwenden Sie immer Ihre eigene Cloud‑URL als Basis. Den genauen Endpunkt entnehmen Sie bitte Ihrer PDFMAILER CLOUD URL.

Bevor Sie den Endpunkt nutzen können, müssen ein paar Dinge erfüllt sein:

  • Berechtigung: Ihr Portal‑Benutzer braucht die Berechtigung zum Versenden von Dokumenten.
  • DSGVO‑AVV: Der Auftragsverarbeitungsvertrag muss für das Portal einmalig akzeptiert worden sein.
  • Zugang: Ein aktives PDFMAILER‑Trial oder ein entsprechend gebuchter API‑Zugang.

Authentifizierung

Jeder Aufruf braucht Authentifizierung. Es gibt drei Wege:

MethodeSo geht's
Bearer‑TokenEmpfohlen. Header Authorization: Bearer <token>. Token erzeugen Sie selbst in der PDFMAILER.CLOUD (siehe unten).
Basic AuthHTTP‑Basic‑Authentifizierung mit Ihren Benutzer‑Zugangsdaten, falls Ihr Client kein OAuth2/Bearer unterstützt.
__sidGültige Session‑ID als Parameter __sid (GET oder POST) bei jedem Request mitsenden.
API‑Token selbst erzeugen

Ihren API‑Token erzeugen Sie direkt in der PDFMAILER.CLOUD unter Einstellungen → Account und Sicherheit → REST API → „API erzeugen". Dort finden Sie außerdem einen Link zur Swagger UI.

Boolean‑Werte

Boolesche Parameter werden als 1 (true) bzw. 0 (false) übergeben.

API‑Version

Über version (1 bis 3, aktuell empfohlen 3) wählen Sie das API‑Verhalten. Verschiedene Versionen arbeiten unterschiedlich. Setzen Sie die Version nur bewusst. Das Portal kann eine Mindestversion vorgeben, die nicht unterschritten werden kann.

03So funktioniert es

Fünf Schritte vom JSON zur fertigen eRechnung.

  1. Authentifizieren

    Bearer‑Token besorgen und im Authorization‑Header mitschicken. Sicherstellen, dass Berechtigung und Zugang passen.

  2. JSON‑Objekt aufbauen

    Die Rechnungsdaten im Feld json als JsonDocument‑Objekt zusammenstellen: seller, buyer, header, items sowie (falls nicht per Auto‑Complete ergänzt) vat, summary, payment.

  3. Zielformat & Optionen wählen

    Über transform das Format bestimmen (ZUGFeRD oder XRechnung). tryAutoComplete: 1 lässt fehlende Werte aus Portal‑ und Empfängerdaten ergänzen. fileName festlegen (bei Versand mit Endung .pdf).

  4. Request senden

    Als POST mit Content-Type: application/json an /json. Wahlweise Versandziel (email), Archivierung oder getFileOnly für reinen Download angeben.

  5. Antwort auswerten

    Standardmäßig kommt die Dokument‑ID zurück. Mit getResponse ein Antwortobjekt, mit getFileOnly die Datei, mit asynchronous ein Request‑Token zum Abholen. testUpload liefert vorab das Testergebnis, ohne Credits zu verbrauchen.

04Das JSON‑Objekt

Der Kern ist das Objekt im Feld json (Typ gotomaxx_JsonDocument). Es gliedert sich in klar getrennte Bereiche. Zur Orientierung ist bei vielen Feldern als Referenz der zugehörige BT‑xx‑Code der EN‑16931‑Norm angegeben, auf den das Feld abgebildet wird.

Pflicht muss angegeben werden Auto per Auto‑Complete ergänzbar nur XRechnung für XRechnung erforderlich BT‑1 Norm‑Referenz

seller: Verkäufer / Rechnungssteller

Ihre eigenen Firmendaten. Viele Kontakt‑ und Bankfelder können aus den Portal‑Metadaten ergänzt werden.

FeldTypBeschreibung
namestringFirmenname
Pflicht
addressLinestringStraße / Adresszeile
Pflicht
addressLine2/3stringWeitere Adresszeilen
zipstringPostleitzahl
Pflicht
citystringOrt
Auto aus PLZ
countryenumLändercode (DE, AT, CH …)
Auto
idstringVerkäufer‑ID BT‑29
tradingNamestringHandelsname BT‑28
taxIdtaxidSteuernummer / USt‑IdNr. BT‑31 (validiert)
taxRegIdstringSteuer‑Registrierungs‑ID BT‑32
ibanibanIBAN BT‑84
Auto aus Portal
bicbicBIC BT‑86
Auto
bankAccountOwnerstringKontoinhaber BT‑85
contactNamestringAnsprechpartner BT‑41
Auto
contactPhonetelTelefon BT‑42
Auto
contactEmailemailE‑Mail BT‑43
Auto
endPointstringElektronische Adresse
nur XRechnungAuto
endPointTypeenumSchema: EM, 0204, 9930, 0060
nur XRechnung

buyer: Käufer / Rechnungsempfänger Pflicht

Die Empfängerdaten. Kontaktangaben können aus Ihrer Empfänger‑Datenbank ergänzt werden.

FeldTypBeschreibung
idstringKäufer‑ID BT‑46
Pflicht
addressobjectAnschrift (name, addressLine, zip, city, country)
Pflicht
taxIdtaxidSteuernummer BT‑48
contactNamestringAnsprechpartner BT‑56
contactPhonetelTelefon BT‑57
Auto
contactEmailemailE‑Mail BT‑58
Auto
endPointstringElektronische Adresse
nur XRechnungAuto
endPointTypeenumEM, 0204, 9930, 0060
nur XRechnung

header: Rechnungskopf Pflicht

FeldTypBeschreibung
idstringRechnungsnummer BT‑1
Pflicht
typeenumRechnungsart, z. B. 380 Rechnung, 326 Teilrechnung, 384 Korrektur, 381 Gutschrift
currencyenumWährung, z. B. EUR
datedateRechnungsdatum BT‑2 (YYYY-MM-DD)
Auto = heute
deliverydateLieferdatum BT‑72
Auto = Rechnungsdatum
routingstringLeitweg‑ID BT‑10
nur XRechnung
buyerIdstringKäufer‑Referenz BT‑13
notestringFreitext‑Hinweis BT‑22
project / contract / salesstringProjekt‑ BT‑11, Vertrags‑ BT‑12, Auftrags‑Referenz BT‑14
tender / objectstringAusschreibungs‑ BT‑17, Objekt‑Referenz BT‑18
periodStart / periodEnddateAbrechnungszeitraum BT‑73/74
precedingInvoiceId / …Datestring / dateVorausgehende Rechnung BT‑25/26
vatExceptReasonstringGrund für Steuerbefreiung BT‑120
testbooleanTest‑Kennzeichen im Dokument

items[]: Rechnungspositionen Pflicht

Mindestens eine Position. Preise und Summen sind rechnerisch verknüpft und können weitgehend automatisch ergänzt werden (siehe Formeln unten).

FeldTypBeschreibung
namestringBezeichnung BT‑153
Pflicht
quantitynumberMenge BT‑129
unitenumEinheit (UN/ECE), z. B. H87 Stück, HUR Stunde, KGM kg, LTR Liter, MTR Meter
netnumberNettopreis BT‑146
Auto aus gross
grossnumberBruttopreis BT‑148
Auto aus net
discountnumberRabatt (netto) BT‑147
baseQuantitynumberPreis‑Basismenge BT‑149
vatnumberUSt‑Satz in % BT‑152
Auto
vatCategoryenumUSt‑Kategorie BT‑151 (S, Z, E, AE …)
Auto
totalnumberPositionssumme BT‑131
Auto
lineIdstringPositionsnummer BT‑126
Auto = Index
sellerId / buyerIdstringArtikel‑Nr. Verkäufer BT‑155 / Käufer BT‑156
notestringPositions‑Hinweis BT‑127
allowance[]arrayPositionsbezogene Zu‑/Abschläge: type (CHARGE), amount BT‑136/141, reason Pflicht BT‑139/144
USt‑Kategorien (vatCategory)

S Regelsteuersatz · Z Nullsatz · E steuerbefreit · AE Reverse‑Charge · K innergem. Lieferung · G Ausfuhr steuerfrei · O nicht steuerbar · L/M Kanaren / Ceuta & Melilla.

vat[]: Steueraufstellung

Auto Wird aus Positionen und Zu‑/Abschlägen berechnet. Nur nötig, wenn Sie die Aufstellung selbst kontrollieren wollen.

FeldFormel / Bedeutung
vat BT‑119Pflicht Steuersatz in %
vatCategory BT‑118USt‑Kategorie, z. B. S
amount BT‑116Σ items.total − Σ allowance + Σ charge
vatAmount BT‑117amount / 100 × vat

summary: Rechnungssummen

Auto Ebenfalls vollständig berechenbar. Die Verknüpfungen:

FeldFormel
total BT‑106Σ items.total
allowance BT‑107Σ allowance.amount
charge BT‑108Σ charge.amount
net BT‑109Σ vat.amount
tax BT‑110Σ vat.vatAmount
gross BT‑112net + tax
prepaid BT‑113Bereits gezahlter Betrag
due BT‑115gross − prepaid

payment: Zahlungsangaben

FeldTypBeschreibung
idstringVerwendungszweck / Referenz BT‑83
Pflicht
duedateFälligkeitsdatum BT‑9
Auto = Rechnungsdatum + 7 Tage
termsstringZahlungsbedingungen BT‑82
paymentenumZahlungsart‑Code BT‑81, z. B. 30 Überweisung, 58 SEPA‑Überweisung, 59 SEPA‑Lastschrift, 10 Bar, 57 Ständige Vereinbarung
descriptionstringBeschreibung BT‑20

allowance[]: Zu‑ & Abschläge (Beleg‑Ebene)

Rabatte oder Zuschläge, die für die gesamte Rechnung gelten.

FeldTypBeschreibung
typeenumCHARGE (Zuschlag) oder ALLOWANCE (Abschlag)
amountnumberNettobetrag BT‑92
reasonstringGrund BT‑97
Pflicht
vatnumberUSt‑Satz in % BT‑96
Auto
vatCategoryenumUSt‑Kategorie BT‑95 (S, Z, E, AE …)
Auto

shipping: Lieferanschrift

Optional. Gleicher Aufbau wie eine Adresse.

FeldTypBeschreibung
namestringName
Pflicht
addressLinestringAdresszeile
Pflicht
addressLine2/3stringWeitere Adresszeilen
zipstringPostleitzahl
Pflicht
citystringOrt
Auto aus PLZ
countryenumLändercode (DE, AT, CH …)
Auto

attachments[]: Anhänge

Auto Standardmäßig leer. Über Anhänge liefern Sie zusätzliche Belege (Rechnungsdatenblatt, Referenzpapier) als Base64 oder ein eigenes Sicht‑PDF (siehe unten).

FeldTypBeschreibung
idstringID BT‑122
Pflicht
namestringBezeichnung BT‑123
Pflicht
fileNamestringDateiname
Pflicht
filebase64Dateiinhalt BT‑125. Pflicht, außer es ist die erzeugte PDF (isPdf)
mimeenumPDF, PNG, JPEG, CSV, OXML, ODOC
typeenum50 geprüftes Angebot · 130 Rechnungsdatenblatt · 916 Referenzpapier
isPdfbooleanMarkiert das PDF, das als Sichtdokument dient (nur bei genau einem Anhang true). Bei ZUGFeRD wird es zum PDF‑Träger, bei XRechnung ins XML eingebettet.
Eigenes Sicht‑PDF für ZUGFeRD

Bei ZUGFeRD können Sie ein eigenes PDF als Sichtdokument vorgeben, also den sichtbaren, lesbaren Teil, in den die XML eingebettet wird. Dazu hängen Sie das PDF als Anhang mit isPdf: true an (nur bei genau einem Anhang zulässig).

Ohne eigenes Sicht‑PDF rendert die API automatisch ein PDF aus Ihren Belegdaten.

jsonEigenes Sicht‑PDF anhängen
"attachments": [
  {
    "id": "0",
    "name": "test",
    "isPdf": true,
    "mime": "PDF",
    "fileName": "Rechnung",
    "file": "JVBERi0xLjcKJdPr6e…"
  }
]

Auszug aus dem json‑Objekt. file enthält die Base64‑Daten des PDF (hier gekürzt).

05Auto‑Complete verstehen

Mit tryAutoComplete: 1 ergänzt der Dienst fehlende Pflichtangaben aus Portal‑Metadaten, Ihrer Empfänger‑Datenbank und aus rechnerischen Zusammenhängen. Das reduziert Ihr JSON auf das Wesentliche.

Wichtig: keine Korrektur

Auto‑Complete ist keine Auto‑Korrektur. Angegebene Werte müssen korrekt sein: Sie werden ergänzt, aber nicht repariert. Falsche Werte führen zu Validierungsfehlern.

Verarbeitungsreihenfolge

Die Ergänzung läuft in fester Reihenfolge, spätere Blöcke bauen auf früheren auf:

seller → Standard‑USt (aus Portal) → buyer → shipping → header → payment → items → allowance → vat → summary → attachments

Validierte Werte

Wo möglich werden Werte geprüft: Steuernummer · E‑Mail · Telefon · IBAN · BIC · Enum‑Werte · Werttypen · PLZ · MIME‑Typ.

Praxis

Mit testUpload: 1 lassen Sie die Transformation inkl. Auto‑Complete durchspielen und sehen das Ergebnis, ohne Credits zu verbrauchen. Ideal beim Aufbau Ihres JSON.

06XRechnung vs. ZUGFeRD

Beide Formate entstehen aus demselben JSON, gesteuert über den Parameter transform. Sie unterscheiden sich im Ergebnis und in den Pflichtangaben.

transform: "ZUGFeRD"

Erzeugt eine PDF/A‑3B mit eingebettetem factur‑x.xml im ZUGFeRD Comfort‑Profil. Standard beim JSON‑Upload.

  • Menschenlesbares PDF + maschinenlesbares XML in einem
  • Sicht‑PDF automatisch aus den Belegdaten, alternativ eigenes PDF via attachments (isPdf)
  • pdfa ist hier immer true

transform: "XRechnung"

Erzeugt eine XRechnung.xml im XRechnung CII‑Format. Optional zusätzlich als PDF/A‑3B (über pdfa).

  • Mit attach: 1 wird die XRechnung.xml angehängt
  • Benötigt separate Lizenz & Berechtigung

Zusätzliche Pflichtfelder für XRechnung

FeldBedeutung
header.routingLeitweg‑ID BT‑10 des Rechnungsempfängers (z. B. bei Behörden)
seller.endPoint + endPointTypeElektronische Adresse des Verkäufers (Auto‑Complete aus Portal möglich)
buyer.endPoint + endPointTypeElektronische Adresse des Käufers (Auto‑Complete aus Kundendaten möglich)
Wichtig

Die transform‑Optionen gelten nur beim Upload von JSON (oder XML). Beim direkten Upload von fertigem ZUGFeRD‑ oder XRechnung‑Material stehen sie nicht zur Verfügung. Beim JSON‑Upload ohne Angabe wird ZUGFeRD verwendet.

07Request‑Optionen (Hülle)

Neben json steuern diese Felder Format, Versand, Rückgabe und Verarbeitung.

Format & Erzeugung

FeldTypBeschreibung
jsonobject/stringDie Rechnungsdaten (JsonDocument)
Pflicht
fileNamestringDateiname des Ergebnisses. Bei Versand muss er auf .pdf enden.
Pflicht
transformenumNone · ZUGFeRD · XRechnung · PDFA
pdfaboolErgebnis als PDF/A‑3B. Bei ZUGFeRD/PDFA immer aktiv; wirkt bei XRechnung/JSON/XML.
attachboolBei XRechnung: die XRechnung.xml anhängen?
tryAutoCompleteboolFehlende Werte automatisch ergänzen?
versionintAPI‑Version (1 bis 3, empfohlen 3)

Versand & Empfänger

FeldTypBeschreibung
emailemailEmpfänger‑E‑Mail‑Adresse
emailSenderintID des Absenders
customerstringKundennummer (identifiziert bekannten Kunden)
customerGroupintKundengruppen‑ID
copyRecipientDataboolEmpfängerdaten aus buyer für den Versand übernehmen?
sourcestringFreie Quellkennung (woher kam der Upload)
sendingProfileintVersandprofil. -2 Profil des bekannten Kunden · -1 Standardprofil · 0 individuelles Profil des Kunden

Rückgabe & Verarbeitung

FeldTypBeschreibung
getResponseboolAntwortobjekt statt reiner Dokument‑ID. Nicht mit getFileOnly kombinierbar.
getFileOnlyboolNur die erzeugte Datei (ZUGFeRD‑PDF / XRechnung‑XML) als Download, ohne Versand. Nicht mit getResponse.
testUploadboolNur testen (Transformationen, nicht den finalen Import). Kostet keine Credits.
asynchronousboolAsynchron verarbeiten, liefert ein Request‑Token zum Abholen des Ergebnisses.
responseWebHookuriWebhook‑URL, an die das asynchrone Ergebnis als JSON gesendet wird (muss mit HTTP 200 quittieren).
archiveobjectArchivierungs‑Optionen: inbox, folder, type/typeId, tags[], fields[], note, sender, recipient, email, archive.
Asynchron im Detail

Async‑Requests werden in Eingangsreihenfolge verarbeitet (keine Zeitgarantie). Das Ergebnis können Sie per Token abfragen (Endstatus Ok/Error) oder per Webhook empfangen (OkHook/ErrorHook). Nicht abgeholte Daten werden nach einem Tag gelöscht. Test‑Uploads laufen nie asynchron.

08Antworten & Status

Was bei 200 zurückkommt, hängt von Ihren Optionen ab:

Bei …Rückgabe
StandardDokument‑ID
getResponse: 1Antwortobjekt
getFileOnly: 1Die Datei selbst (ZUGFeRD‑PDF oder XRechnung‑XML) mit passendem MIME‑Header
asynchronous: 1Request‑Token
testUpload: 1Testergebnis

HTTP‑Statuscodes

CodeBedeutung
200OK: Dokument‑ID / Objekt / Token / Datei / Testergebnis
400Bad Request: Fehlermeldung als String
401Unauthorized: Authentifizierung fehlt/ungültig
403Forbidden: Berechtigung oder Zugang fehlt
500Interner Serverfehler
503Wartung: später erneut versuchen

Antwortobjekt & Validierungsfehler

Mit getResponse: 1 (sowie bei testUpload: 1) erhalten Sie statt der reinen Dokument‑ID ein strukturiertes Antwortobjekt mit dem erzeugten Dokument und dem Validierungsergebnis. Das Objekt wird auch dann geliefert, wenn das Dokument ungültig ist. Prüfen Sie deshalb immer das Feld valid. Schlägt die Validierung fehl, trägt error eine Kurzmeldung und das jeweilige …Error‑Feld den ausführlichen Prüfbericht.

FeldBedeutung
idID des erzeugten Dokuments
validIst das erzeugte Dokument gültig? true / false
errorKurze Fehlerbeschreibung (z. B. "XRechnung validation failed"), sonst null
type / targetEingabeformat (z. B. JSON) und Zielformat (z. B. XRechnung3CII)
xrechnung / zugferdDas erzeugte XRechnung‑XML bzw. ZUGFeRD‑PDF (auch bei Validierungsfehlern enthalten)
xml / jsonDie intern gemappten Daten und das verarbeitete JSON
pdf / htmlErzeugtes Sicht‑PDF bzw. HTML, falls vorhanden
xrechnungError
zugferdError
Ausführlicher Prüfbericht bei Validierungsfehlern (KoSIT‑Validator‑Report): listet jede verletzte EN‑16931‑/XRechnung‑Regel mit Regelcode, Meldung und XPath‑Position
xmlError / jsonError
pdfError / htmlError
Fehler im jeweiligen Verarbeitungsschritt, sonst null
runtimeVerarbeitungsdauer
jsonAntwortobjekt bei Validierungsfehler (gekürzt)
{
  "id": 671,
  "test": false,
  "valid": false,
  "error": "XRechnung validation failed",
  "type": "JSON",
  "target": "XRechnung3CII",
  "xrechnung": "<?xml … </rsm:CrossIndustryInvoice>",
  "zugferd": null,
  "xml": "<?xml … </DataDefinition>",
  "json": "{…}",
  "pdf": null,
  "html": null,
  "xrechnungError": "<rep:report valid='false'> … [BR-E-05] … BT-152 shall be 0 (zero) … </rep:report>",
  "zugferdError": null,
  "runtime": 0
}

Der Prüfbericht in xrechnungError nennt die konkrete Ursache, im Beispiel u. a. BR‑E‑05: Bei USt‑Kategorie „steuerbefreit" (E) muss der Steuersatz 0 % betragen.

09Vollständiges Beispiel

1 · ZUGFeRD erzeugen & per E‑Mail versenden

Minimaler Request mit Auto‑Complete: Beträge und Summen werden ergänzt.

jsonRequest‑Body
{
  "fileName": "rechnung-2026-001.pdf",
  "transform": "ZUGFeRD",
  "tryAutoComplete": 1,
  "copyRecipientData": 1,
  "email": "kunde@example.com",
  "json": {
    "seller": {
      "name": "Muster GmbH",
      "addressLine": "Musterstraße 1",
      "zip": "76870",
      "city": "Kandel",
      "country": "DE",
      "taxId": "DE123456789"
    },
    "buyer": {
      "id": "K-1001",
      "address": {
        "name": "Beispiel AG",
        "addressLine": "Beispielweg 5",
        "zip": "10115",
        "city": "Berlin",
        "country": "DE"
      }
    },
    "header": {
      "id": "2026-001",
      "type": "380",
      "currency": "EUR",
      "date": "2026-07-02"
    },
    "payment": {
      "id": "RE 2026-001",
      "payment": "58"
    },
    "items": [
      {
        "name": "Beratungsleistung",
        "quantity": 10,
        "unit": "HUR",
        "net": 120.00,
        "vat": 19,
        "vatCategory": "S"
      }
    ]
  }
}

Der passende HTTP‑Aufruf:

bashcURL
# Erzeugt & versendet die ZUGFeRD-Rechnung, gibt die Dokument-ID zurück
# IhrFirmenname durch den Namen Ihrer eigenen PDFMAILER CLOUD ersetzen
curl -X POST "https://post.gotomaxx.com/IhrFirmenname/service/rest/outgoing/json" \
  -H "Authorization: Bearer IHR_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @rechnung.json

2 · XRechnung erzeugen (nur Datei, kein Versand)

Zusatzfelder für XRechnung: routing sowie endPoint/endPointType. Mit getFileOnly bekommen Sie das XML direkt zurück, mit testUpload prüfen Sie vorab.

jsonRequest‑Body (Auszug)
{
  "fileName": "xrechnung-2026-001.xml",
  "transform": "XRechnung",
  "tryAutoComplete": 1,
  "getFileOnly": 1,
  "testUpload": 1,
  "json": {
    "seller": {
      "name": "Muster GmbH",
      "addressLine": "Musterstraße 1",
      "zip": "76870", "city": "Kandel", "country": "DE",
      "endPoint": "info@muster-gmbh.de",
      "endPointType": "EM"
    },
    "buyer": {
      "id": "K-1001",
      "endPoint": "991-12345-67",
      "endPointType": "0204",
      "address": { "name": "Behörde XY", "addressLine": "Amtsweg 3",
        "zip": "10115", "city": "Berlin", "country": "DE" }
    },
    "header": {
      "id": "2026-001", "type": "380", "currency": "EUR",
      "routing": "04011000-1234512345-06"  // Leitweg-ID (BT-10)
    },
    "items": [
      { "name": "Lizenzgebühr", "quantity": 1, "unit": "H87",
        "net": 500.00, "vat": 19, "vatCategory": "S" }
    ]
  }
}

Hinweis: JSON kennt keine Kommentare. Die //‑Anmerkungen dienen hier nur der Erklärung und müssen im echten Request entfernt werden.

10Tipps & Fallstricke

  • Booleans als 1/0: Alle bool‑Parameter als 1 oder 0 übergeben.
  • Dateiname bei Versand: Soll versendet werden, muss fileName auf .pdf enden.
  • Sich ausschließende Optionen: getResponse und getFileOnly nicht zusammen. Mit getFileOnly findet kein Versand statt.
  • Erst testen: testUpload: 1 nutzen, um JSON und Transformation zu prüfen, ohne Credits zu verbrauchen (der finale PDF‑Import wird dabei nicht ausgeführt).
  • Auto‑Complete ≠ Korrektur: Gelieferte Werte müssen korrekt sein: Validierung greift bei Steuernummer, IBAN, BIC, E‑Mail, Telefon, PLZ, Enums, MIME.
  • XRechnung‑Pflichten: routing sowie endPoint/endPointType für Verkäufer und Käufer nicht vergessen (oder Auto‑Complete sicherstellen).
  • Eigenes Sicht‑PDF: Bei ZUGFeRD über attachments mit isPdf: true ein eigenes PDF als Sichtdokument vorgeben; ohne Angabe rendert die API es automatisch aus den Belegdaten.
  • Async‑Ergebnis verfällt: Nicht abgeholte asynchrone Ergebnisse werden nach einem Tag gelöscht.
  • Version bewusst wählen: API‑Versionen verhalten sich unterschiedlich; das Portal kann eine Mindestversion erzwingen.
Empfohlener Einstieg

Klein anfangen: seller, buyer, header und eine items‑Position mit net, vat, vatCategory, dazu tryAutoComplete: 1 und testUpload: 1. Passt das Testergebnis, testUpload entfernen und Versand‑ bzw. Rückgabeoptionen ergänzen.

gotomaxx Outgoing REST API · Endpunkt POST /json · Diese Doku fasst die Swagger‑Spezifikation praxisorientiert zusammen. Bei Fragen oder Problemen wenden Sie sich gerne an unseren Helpdesk unter helpdesk.gotomaxx.com.