Die Lexware Office API: Einstieg, erste Rechnung, harte Grenzen

Die Public API von Lexware Office ist eine REST-Schnittstelle, über die eigene Systeme Kontakte, Belege und Rechnungen in der Buchhaltung anlegen und auslesen können. Zwei Dinge entscheiden darüber, ob Sie sie überhaupt nutzen können: Sie brauchen den XL-Tarif, und Sie brauchen einen eigenen Schlüssel aus Ihrem Konto. Alles andere ist Handwerk — allerdings Handwerk mit ein paar Regeln, die man besser vorher kennt als nach der ersten Fehlermeldung.

Wer aus einem CRM heraus Rechnungen erzeugen will, landet früher oder später genau hier. Der Weg über eine fertige App endet dort, wo die eigenen Abläufe anfangen: eigene Felder, eigene Nummernlogik, eigene Auslöser. Dann führt kein Weg an der Schnittstelle vorbei.

Heißt es jetzt lexoffice oder Lexware Office?

Beides bezeichnet dasselbe Produkt, aber nur ein Name ist aktuell: Lexware Office. Der Namenswechsel hat auch die Technik erfasst, und das ist für Sie relevant, weil noch immer Anleitungen mit den alten Adressen kursieren.

Seit dem 26. Mai 2025 läuft die Schnittstelle laut der Entwicklerdokumentation von Lexware über das neue Gateway unter https://api.lexware.io. Die Erreichbarkeit der alten Basisadresse war nur bis Dezember 2025 zugesichert. Wenn Sie also auf eine Anleitung stoßen, die api.lexoffice.io nennt, ist sie veraltet — der Aufbau der Aufrufe ist derselbe geblieben, nur der Hostname hat gewechselt.

Für die Suche heißt das: „lexoffice API" und „Lexware Office API" meinen dieselbe Sache. Für Ihren Code heißt es: Prüfen Sie die Basisadresse, bevor Sie einen Fehler bei sich suchen.

Was brauchen Sie, bevor der erste Aufruf der lexoffice API funktioniert?

Drei Dinge: den passenden Tarif, einen Schlüssel und den richtigen Kopfzeilen-Eintrag in jeder Anfrage.

Der Tarif ist die Hürde, an der die meisten zuerst hängen bleiben. Die Public API ist dem XL-Tarif vorbehalten; in den kleineren Paketen lässt sich schlicht kein Schlüssel erzeugen. Das ist keine Einstellung, die sich freischalten ließe, sondern eine Frage des Abonnements. Details dazu nennt Lexware auf der Funktionsseite zur Public API, im Help Center und auf der Übersicht für Entwickler und Integrationspartner.

Den Schlüssel erzeugen Sie selbst in der Public-API-Verwaltung Ihres Kontos. Er gehört zu Ihrem Konto, nicht zu einer App, und er wird wie ein Passwort behandelt: einmal angezeigt, danach sicher ablegen, niemals in ein öffentliches Repository committen.

Ein Detail sorgt später für stille Ausfälle: Ein Schlüssel gilt höchstens 24 Monate. Mit Erreichen des Ablaufdatums wird er laut Help Center automatisch deaktiviert und gelöscht — die Anbindung steht dann von einem Tag auf den anderen, ohne dass sich im Code etwas geändert hätte. Die gute Nachricht: In der Verwaltung lässt sich das Ablaufdatum um weitere 24 Monate verlängern, und zwar ohne den Schlüssel zu tauschen. Sie müssen also nichts an der Anbindung ändern, nur rechtzeitig verlängern. Tragen Sie sich das Datum ein, sobald Sie den Schlüssel erzeugen.

Übergeben wird er als Bearer-Token im Kopf jeder Anfrage:

Authorization: Bearer IHR_API_SCHLUESSEL
Accept: application/json

Fehlt der Kopfzeilen-Eintrag oder ist der Schlüssel falsch, antwortet der Server mit einem Autorisierungsfehler — nicht mit einer leeren Liste. Das klingt banal, erspart aber eine Stunde Suche, wenn eine Abfrage unerwartet nichts zurückgibt.

Welche Bereiche deckt die Schnittstelle ab?

Die API ist breiter, als die meisten erwarten. Sie endet nicht bei der Rechnung, sondern umfasst den ganzen Belegkreislauf vom Angebot bis zur Mahnung.

Besonders unterschätzt werden die Event Subscriptions. Damit meldet Lexware Office Änderungen aktiv an Ihr System, statt dass Sie im Minutentakt nachfragen. Für eine CRM-Anbindung ist das der Unterschied zwischen einer sauberen Übergabe und einem Skript, das dauernd gegen das Anfragelimit läuft.

Wie erzeugen Sie die erste Rechnung über die Schnittstelle?

In drei Schritten: Kontakt sicherstellen, Beleg anlegen, Ausgabe erzeugen. Der zweite Schritt hat eine Eigenheit, die Sie kennen müssen, bevor Sie etwas bauen.

Zuerst brauchen Sie den Empfänger, und dafür gibt es drei Wege. Sie legen über den Contacts-Endpunkt einen neuen Kontakt an und merken sich dessen Kennung. Oder Sie verweisen im Beleg auf eine bestehende — der stabilere Weg, weil Sie sonst bei jeder Rechnung riskieren, einen Kunden ein zweites Mal anzulegen. Oder Sie übergeben eine Einmal-Adresse direkt am Beleg; dann entsteht in Lexware Office überhaupt kein Kontakt. Für Einmalkunden aus einem Webformular ist das oft die sauberste Lösung.

Dann folgt der Beleg selbst. Pflicht sind laut Dokumentation Rechnungsdatum, Empfängeradresse, Positionen, Gesamtbetrag, Steuerangaben und die Liefer- beziehungsweise Leistungsangaben — die Adresse wahlweise als Verweis auf einen bestehenden Kontakt oder als Einmal-Adresse. Standardmäßig wird sie als Entwurf angelegt; mit dem Parameter finalize=true entsteht stattdessen direkt ein abgeschlossener Beleg mit Nummer.

Hier liegt die eigentliche Falle: Der Status lässt sich über die Schnittstelle nachträglich nicht mehr ändern. Es gibt keinen Aufruf, der einen Entwurf später abschließt, und auch keinen, der eine angelegte Rechnung bearbeitet — anders als bei Kontakten und Artikeln, die sich sehr wohl aktualisieren lassen.

Für die Praxis heißt das: Die Entscheidung fällt beim Anlegen, nicht danach. Wer zum Erproben Entwürfe erzeugt, schließt sie anschließend von Hand in Lexware Office ab oder verwirft sie und legt neu an. Ein Programm, das erst einen Entwurf schreibt und ihn später über die Schnittstelle finalisieren möchte, lässt sich nicht bauen — diese Reihenfolge sieht die API nicht vor.

Warum lässt sich eine ausgestellte Rechnung nicht mehr ändern?

Hier sind zwei Grenzen zu unterscheiden. Über die Schnittstelle ist keine Rechnung änderbar, auch kein Entwurf — einen Aktualisieren-Aufruf gibt es für Rechnungen schlicht nicht. In der Oberfläche von Lexware Office lässt sich ein Entwurf dagegen bearbeiten; dort endet die Änderbarkeit erst mit der Finalisierung. Sobald eine Rechnung den Status „offen" oder „bezahlt" erreicht, ist sie laut Dokumentation auch dort nicht mehr editierbar.

Das ist keine Einschränkung der Schnittstelle, sondern die Logik ordnungsmäßiger Buchführung: Ein ausgestellter Beleg mit fortlaufender Nummer darf nachträglich nicht still verändert werden, sonst wäre die Nachvollziehbarkeit dahin. Korrekturen laufen deshalb über eine Stornorechnung oder eine Gutschrift, nicht über ein Update.

Für Ihre Anbindung heißt das: Die Prüfung muss vor die Finalisierung. Wer erst finalisiert und dann feststellt, dass die Steuerlogik nicht stimmt, räumt hinterher mit Gutschriften auf. Bauen Sie die Freigabe deshalb als eigenen Schritt ein — technisch wie organisatorisch.

Wo stoßen Sie an harte Grenzen?

An vier Stellen, und alle vier sind dokumentiert. Sie treffen niemanden im Testbetrieb, sondern immer erst im Echtbetrieb, wenn Datenmengen dazukommen.

Die wichtigste ist das Anfragelimit: Ein Client darf laut Dokumentation zwei Anfragen pro Sekunde stellen. Wer darüber liegt, bekommt den Status 429, und der Aufruf wird schlicht nicht ausgeführt. Planen Sie dabei Luft ein — die Dokumentation weist ausdrücklich darauf hin, dass bereits das exakte Ausreizen des Limits regelmäßig zu abgelehnten Anfragen führt, weil Laufzeitschwankungen im Netz die Abstände verschieben. Für eine Erstbefüllung heißt das: 5.000 Kontakte dauern bei vollem Tempo rund 42 Minuten reine Übertragungszeit; mit dem nötigen Sicherheitsabstand und Suchabfragen sollten Sie eher mit anderthalb Stunden rechnen.

Dass die 429 auch unterhalb des Limits auftreten kann, zeigt ein über Monate dokumentierter Fall im Forum des Integrationsanbieters Synesty. Ein Anwender bekam beim Abruf von Eingangsrechnungen wiederholt diese Meldung — zunächst nur bei mehreren gleichzeitigen Aufrufen, am Ende auch dann, wenn nur ein einziger eingerichtet war. Die Ursache blieb ungeklärt, eine Anpassung des Anbieters brachte keine Besserung, und der Verlauf endet ohne Lösung. Die Lehre daraus ist nicht eine bestimmte Zahl, sondern die Bauweise: Fangen Sie den Status 429 ab und wiederholen Sie den Aufruf mit wachsender Wartezeit. Genau das empfiehlt auch die Dokumentation.

Dazu kommen drei stille Begrenzungen:

• Ein Beleg darf höchstens 300 Positionen enthalten. Für Sammelrechnungen aus einem CRM mit vielen Kleinposten ist das schneller erreicht, als man denkt.
• Je Kontakt lässt sich über die API nur eine Rechnungs- und eine Lieferadresse aktualisieren, obwohl beim Auslesen mehrere zurückkommen können. Wer mehrere Standorte je Kunde führt, muss das in seinem System lösen, nicht in Lexware Office.
• Der Anmeldeserver hat eigene Limits, und dort wird tatsächlich gesperrt: von wenigen Sekunden bis zu einigen Minuten — und dauerhaft, solange das Tempo nicht sinkt. Ein Skript, das bei jedem Aufruf neu authentifiziert, läuft genau da hinein. Der Schlüssel wird einmal gesetzt und wiederverwendet.

Was heißt das für die Anbindung an ein CRM wie Pipedrive?

Dass die Schnittstelle der einfachere Teil der Arbeit ist. Die eigentliche Frage ist, welche Daten überhaupt übergeben werden — und wann.

Ein CRM kennt Deals, Produkte und Ansprechpartner. Eine Buchhaltung kennt Kunden, Steuersätze und Nummernkreise — welche Software diese Lücke im Alltag schließt, vergleicht unser Überblick zur Faktura-Software am CRM. Dazwischen liegt eine Zuordnung, die niemand geschenkt bekommt: Welches Feld trägt die Steuernummer, was passiert bei abweichender Rechnungsadresse, welcher Zustand im Verkaufsprozess löst den Beleg aus. Diese Fragen entscheiden über den Erfolg, nicht die Wahl der Programmiersprache.

Wie dieser Weg von der anderen Seite aussieht, beschreibt unser Beitrag zu den Wegen von Pipedrive zur Rechnung; die fertige Verbindung zwischen beiden Systemen behandelt der Artikel zur lexoffice-Pipedrive-Integration.

Ein Thema ist dabei schon abgedeckt: Rechnungen lassen sich über die Schnittstelle direkt im XRechnung-Format erzeugen, sofern der Kontakt dafür freigeschaltet ist. Die Leitweg-ID wird als eigenes Feld übergeben, und Lexware Office prüft beim Anlegen strenger als sonst — fehlt eine Pflichtangabe, scheitert der Aufruf, statt einen unbrauchbaren Beleg zu erzeugen.

Der ehrliche Hinweis zum Schluss: Der Eigenbau lohnt sich, wenn Ihre Abläufe eigen sind — eigene Felder, eigene Auslöser, eigene Prüfungen. Für eine Standardübergabe „Deal gewonnen, Rechnung raus" ist er selten die günstigste Lösung, weil nach dem Bauen die Wartung kommt: API-Änderungen, neue Pflichtangaben, wechselnde Formate der elektronischen Rechnung.

Häufige Fragen

Brauche ich für die Lexware Office API zwingend den XL-Tarif? Ja. In den kleineren Tarifen lässt sich kein API-Schlüssel erzeugen. Die Verwaltung dafür finden Sie unter app.lexware.de/addons/public-api.

Was kostet die Nutzung der Schnittstelle zusätzlich? Über den Tarif hinaus fallen für die Public API selbst keine gesonderten Gebühren an. Der Aufwand liegt in Entwicklung und Wartung Ihrer Anbindung.

Funktioniert die alte Adresse api.lexoffice.io noch? Sie antwortet derzeit noch, aber verlassen sollten Sie sich darauf nicht: Zugesichert war die Erreichbarkeit nur bis Dezember 2025. Aktuell ist https://api.lexware.io.

Wie viele Anfragen pro Sekunde sind erlaubt? Zwei. Bei Überschreitung antwortet der Server mit dem Status 429 und führt den Aufruf nicht aus. Eine zeitliche Sperre verhängt nur der Anmeldeserver.

Kann ich eine bereits angelegte Rechnung über die API ändern? Nein. Weder ein Entwurf noch ein abgeschlossener Beleg lässt sich über die Schnittstelle bearbeiten, und auch der Status ist nicht nachträglich änderbar. Korrekturen laufen über Storno oder Gutschrift, Entwürfe über Verwerfen und Neuanlegen.

Gibt es Webhooks, oder muss ich regelmäßig abfragen? Es gibt sie — über Event Subscriptions meldet Lexware Office Änderungen an Ihr System. Das ist dem regelmäßigen Abfragen vorzuziehen, schon wegen des Anfragelimits.