Der Vertrag ist erzeugt,
nicht geschrieben.

Legt Konto und ersten Nutzer an. Der erste Nutzer bekommt die Rolle OWNER und ist sofort angemeldet. Ist die Registrierung im Betrieb geschlossen, antwortet die Route vor jeder Pruefung des Rumpfs mit 403 und errors[0].code = registration-closed; ein Konto entsteht dann nicht.

Mit E-Mail-Adresse und Passwort. Antwortet 200 mit der Sitzung - oder 202, wenn der Nutzer einen zweiten Faktor eingeschaltet hat: dann traegt die Antwort statt der Sitzung einen Beleg (SecondFactorChallenge), und die Sitzung gibt POST /v1/auth/login/totp mit dem Code aus der App aus. Der Beleg gilt fuenf Minuten und fuenf Fehlversuche. Eine Anmeldung mit Passkey (POST /v1/auth/login/passkey) kennt den zweiten Schritt nicht.

Widerruft die Sitzung, mit der der Aufruf kam. Andere Sitzungen bleiben.

Ohne Anmeldung und ohne E-Mail-Adresse: der Browser zeigt die Passkeys, die er fuer diese Domain kennt, und der gewaehlte sagt, wer sich anmeldet. Die Challenge gilt fuenf Minuten und genau fuer POST /v1/auth/login/passkey.

Prueft die Unterschrift gegen den hinterlegten oeffentlichen Schluessel und gibt die Sitzung aus, dieselbe wie bei POST /v1/auth/login. Ein zweiter Faktor wird nicht mehr verlangt: der Authenticator hat den Nutzer schon geprueft. Jede Abweichung ist 401 ohne naehere Angabe: unbekannter Passkey, falsche Herkunft, abgelaufene Challenge, gesperrter Zugang.

Nimmt den Beleg aus der 202-Antwort von POST /v1/auth/login und einen Code: sechs Ziffern aus der App oder einen Wiederherstellungscode. Gibt die Sitzung aus, dieselbe wie bei POST /v1/auth/login. Ein Code gilt einmal: derselbe TOTP-Code wird in seinem Zeitfenster nicht zweimal angenommen, ein Wiederherstellungscode nie. 422 code-invalid bei falschem Code, solange Versuche bleiben. 401, wenn der Beleg unbekannt, abgelaufen oder nach fuenf Fehlversuchen verbraucht ist: dann beginnt die Anmeldung beim Passwort von vorn.

Neueste zuerst, ohne Blaettern: je Nutzer gibt es hoechstens zwanzig. Der oeffentliche Schluessel steht nicht in der Antwort.

Prueft die Antwort von navigator.credentials.create() gegen die Challenge aus Schritt 1 und hinterlegt den oeffentlichen Schluessel. Die Challenge ist danach verbraucht, auch wenn die Pruefung scheitert: fuer einen neuen Versuch beginnt Schritt 1 von vorn. Fehlercodes (422): challenge-expired, passkey-rejected (Herkunft, Unterschrift oder Nutzerpruefung passen nicht).

Gibt die Optionen fuer navigator.credentials.create() aus, samt Challenge. Der Passkey wird als auffindbares Credential mit Nutzerpruefung angelegt (residentKey und userVerification "required"), damit er spaeter ohne E-Mail-Adresse anmeldet und als zweiter Faktor gilt. Schon hinterlegte Passkeys stehen in excludeCredentials; der Browser legt denselben nicht zweimal an. Die Challenge gilt fuenf Minuten und genau fuer POST /v1/auth/passkeys.

Der Passkey meldet danach nicht mehr an. Auf dem Geraet bleibt er stehen, bis der Nutzer ihn dort selbst loescht; das Passwort gilt weiter.

Erzeugt ein neues TOTP-Geheimnis (SHA-1, sechs Ziffern, dreissig Sekunden) und gibt es als Base32 und als otpauth-Link fuer den QR-Code aus. Eingeschaltet ist der Faktor erst nach POST /v1/auth/totp/enable mit einem passenden Code. Ein erneuter Aufruf davor ersetzt das Geheimnis. 409, wenn der Faktor schon eingeschaltet ist: zum Wechsel der App erst ausschalten.

Prueft den Code gegen das Geheimnis aus Schritt 1 und schaltet den Faktor ein. Ab jetzt antwortet POST /v1/auth/login mit 202. Die Antwort traegt 8 Wiederherstellungscodes, jeder einmal gueltig; sie stehen nur hier. Fehlercodes (422): totp-not-set-up (Schritt 1 fehlt), code-invalid. 409, wenn der Faktor schon eingeschaltet ist.

Verlangt das Passwort noch einmal. Loescht Geheimnis und Wiederherstellungscodes; die Anmeldung laeuft danach wieder mit Passwort allein. Wiederholbar: ist kein Faktor eingeschaltet, ist das 204 und nicht 409. Fehlercode (422): password-invalid.

Verlangt das Passwort noch einmal. Die bisherigen Codes, benutzte wie unbenutzte, gelten danach nicht mehr. Fehlercodes (422): password-invalid, totp-not-enabled.

Neueste zuerst. Widerrufene sind nur auf Wunsch dabei.

Der vollstaendige Schluessel steht nur in dieser Antwort. Danach ist in der Datenbank nur noch sein Hash, er laesst sich nicht wiederherstellen.

Der Schluessel bleibt als Zeile bestehen und wird nur entwertet. Geloescht wuerde er aus dem Nachweis verschwinden, wer wann womit gearbeitet hat.

Neueste zuerst, immer nur die der eigenen Umgebung.

Der Rumpf ist das PDF selbst, mit Content-Type application/pdf.

Geprueft wird sofort: Seitenzahl, das Format JEDER Seite und wie stark das Anschriftfeld der ersten Seite belegt ist. Ein PDF, das sich nicht oeffnen laesst, wird mit 422 abgelehnt und hinterlaesst keine Zeile.

Mit B2 wird aus einem Dokument kein Brief mehr: der Brief entsteht aus der Vorlage einer Kampagne. Dokumente ruhen bis v1.1.

Dasselbe PDF ein zweites Mal ergibt dasselbe Dokument und 200 statt 201. Die Pruefung laeuft nicht erneut.

Liefert die abgelegte Datei unveraendert zurueck. Diese Route fuehrt als einzige nur ihren Erfolgsfall im Vertrag: produces gilt in OpenAPI fuer alle Antworten einer Route, und die Fehler waeren damit faelschlich als application/pdf ausgewiesen. Sie kommen wie ueberall als problem+json, siehe das Schema Problem.

Je Produkt der Preis, der jetzt gilt. v1 kennt genau eines, den Standardbrief: unitCredits je mailItem, Porto inbegriffen. Ein Versandauftrag kostet unitCredits * Anzahl der mailItems.

Der Preis ist eine Ganzzahl in Credits. Was ein Credit in Euro kostet, steht in der Credit-Staffel unter GET /v1/credit-prices.

Ohne Zugang abrufbar: das ist der Listenpreis, der auf der Preisseite steht. Ein Interessent muss ihn vor der Registrierung sehen.

Ist noch kein Preis hinterlegt, antwortet die Route mit 503.

Was ein Credit beim Kauf netto kostet, je Menge. Ein Standardbrief kostet einen Credit, Porto inbegriffen.

Die erreichte Stufe gilt fuer die ganze Menge, nicht stufenweise. Die Umsatzsteuer kommt dazu und wird einmal auf die Summe gerundet; was ein Kauf genau kostet, rechnet GET /v1/credit-prices/quote.

Ohne Zugang abrufbar. Gilt keine Staffel, antwortet die Route mit 503 credit-price-missing.

Was ein Kauf dieser Menge nach der geltenden Staffel kostet: Stufe, netto, Umsatzsteuer und brutto. Dieselbe Rechnung wie beim Kauf.

Laesst sich der Betrag nicht in einem Kauf bezahlen (unter 0,50 EUR oder ueber 999 999,99 EUR brutto), antwortet die Route mit 422 credit-quantity-out-of-range. Ohne Zugang abrufbar.

Neueste zuerst, immer nur die des eigenen Kontos. Jede mit dem Inhalt ihrer neuesten Fassung. status grenzt ein; ohne ihn kommen aktive und archivierte.

Legt eine Vorlage mit Fassung 1 an: Name, Text und Variablen. Den Absender kennt die Vorlage nicht; der gehoert zur Kampagne.

Geprueft wird gesetzt, nicht gezaehlt. Der Text geht durch dieselbe Satzrechnung, die spaeter druckt. Abgelehnt wird mit 422 am Feld text, wenn er schon in seiner kuerzesten Gestalt — alle Variablen leer — nicht auf die Seite passt, wenn ein Zeichen nicht druckbar ist, oder wenn ein Platzhalter keine Variable hat (unknown-placeholder): stuende {{betrga}} im Text und hiesse die Variable betrag, stuende das auf jedem gedruckten Brief woertlich so da. Ob der Text mit gefuellten Variablen passt, entscheidet sich je Brief bei der Annahme.

Ein Konto legt hoechstens 1000 Vorlagen je Kalenderjahr (UTC) an, archivierte mitgezaehlt; darueber 422 template-limit-reached. Jede Vorlage verbraucht eine Nummer aus einem Zaehler je Jahr, an dem auch die Registrierung haengt. Neue Fassungen zaehlen nicht.

Die Kopfzeile Idempotency-Key ist Pflicht: jede Vorlage verbraucht eine laufende Nummer ihrer Kennung, und ein Timeout darf daraus keine zwei machen. Derselbe Schluessel ergibt dieselbe Vorlage; die Wiederholung traegt den Status des ersten Aufrufs und Idempotent-Replay: true.

Vorlagen haben keine Umgebung: ein Test- und ein Live-Schluessel sehen dieselben Vorlagen. Eine Vorlage traegt keine Empfaengerdaten und wird nie selbst gedruckt.

Nur Vorlagen des eigenen Kontos; eine fremde ist ein 404.

Ersetzt Name, Text und Variablen vollstaendig. Kein PATCH: eine Vorlage, die sich in Teilen aendern laesst, ist eine, deren Zustand nach zwei Aufrufen niemand mehr kennt.

Weichen Text oder Variablen von der neuesten Fassung ab, entsteht eine neue Fassung. Sie wird geprueft wie bei der Anlage (422 am Feld text). Kampagnen bleiben auf ihrer Fassung; eine neuere erreicht sie erst ueber PUT /v1/campaigns/{id}/template-version, wo die wartenden Briefe durchgerechnet werden. Bearbeiten ist deshalb nie riskant. Aendert sich nur der Name, entsteht keine Fassung. Aendert sich nichts, ist die Antwort dieselbe Vorlage — eine Wiederholung schadet nicht.

baseVersion nennt die Fassung, auf der die Aenderung aufsetzt. Ist inzwischen eine neuere entstanden, oder war ein gleichzeitiger Aufruf schneller, kommt 409 template-version-conflict statt eines stillen Ueberschreibens.

baseVersion schuetzt Text und Variablen. Der Name ist keine Fassung: aendert sich nur er, gilt der zuletzt geschriebene - ausser es ist dazwischen eine neue Fassung entstanden, dann ebenfalls 409.

Eine archivierte Vorlage nimmt keine Aenderung mehr an: 422 template-not-active.

Neueste zuerst. Eine Fassung aendert sich nie und verschwindet nicht, solange es das Konto gibt — auch keine, auf die keine Kampagne mehr zeigt.

Text und Variablen genau dieser Fassung, unveraenderlich.

Die Vorlage laesst sich fuer keine neue Kampagne mehr waehlen und bekommt keine neue Fassung. Kampagnen, die eine ihrer Fassungen drucken, laufen weiter und duerfen zwischen ihren Fassungen wechseln.

Die Standardvorlage laesst sich nicht archivieren (422 template-is-default): erst eine andere zur Standardvorlage machen.

Zweimal archivieren ist derselbe Zustand und kein Fehler. Es gibt keinen Weg zurueck; wer eine archivierte Vorlage wieder braucht, legt sie mit ihrem Text neu an.

Macht diese Vorlage zur Standardvorlage des Kontos; die bisherige verliert die Rolle und bleibt sonst, wie sie ist. Eine Kampagne ohne templateId bekommt kuenftig diese. Kampagnen, die schon bestehen, aendern sich nicht.

Jedes Konto hat genau eine Standardvorlage; die Datenbank haelt das fest. Ist diese Vorlage es schon, ist das kein Fehler. Eine archivierte Vorlage laesst sich nicht dazu machen: 422 template-not-active.

Werte rein, gesetzte Seite raus — fuer die neueste Fassung oder einen ungespeicherten Entwurf (template). Der Editor holt die Vorschau vom Server und baut das Layout nicht nach: eine zweite Fassung des Satzes waere der Fehler, den niemand bemerkt, bis die Vorschau etwas verspricht, das der Drucker nicht haelt.

Ein Entwurf geht durch dieselbe Pruefung wie PUT /v1/templates/{id}: Schema (400); Platzhalter ohne Variable, ein Zeichen, das der Satz nicht kennt, und ein Text, der schon leer nicht auf die Seite passt (422 am Feld template.text). Gespeichert wird nichts.

Im Fenster steht sender, wenn er mitkommt — etwa der Absender einer Kampagne —, sonst ein erkennbar erfundener Musterabsender. Ein Absender, der das Anschriftfeld sprengt, ist 422 am Feld sender.

Ueber die Kopfzeile Accept waehlt der Aufrufer die Form: application/pdf liefert genau das Artefakt, das spaeter gedruckt wird; image/png dieselbe Seite gerastert, aus der PDF. Ohne Angabe kommt PDF. Die Seite ist fluechtig und wird nirgends gespeichert.

values ist freiwillig, und Pflichtvariablen werden hier nicht erzwungen. Was fehlt, bleibt leer; nur eine mehrzeilige Variable (TEXT) ohne Wert zeigt einen Mustertext, damit die Seite nicht leer ist — die Standardvorlage besteht aus nichts als {{text}}. Ein ausdrueckliches "" bleibt leer.

422 an values.<name>: unknown-variable, unsupported-character (ein Zeichen, das sich nicht drucken laesst, ein Zeilenumbruch in einer einzeiligen Variable) und body-too-long, wenn sich der Ueberlauf genau einer mehrzeiligen Variable zuschreiben laesst, sonst an values. Passt die Seite nicht, kommt 422 und kein Bild.

Fehler kommen wie ueberall als application/problem+json, siehe das Schema Problem: 400, 401, 403, 404 und 422. Der Vertrag fuehrt nur den Erfolgsfall, weil produces fuer alle Antworten einer Route gilt.

Neueste zuerst, immer nur die des eigenen Kontos und der eigenen Umgebung. templateId grenzt auf die Kampagnen ein, die eine Fassung dieser Vorlage drucken.

v1 liefert ausschliesslich Kampagnen mit product: LETTER_STANDARD. Postkarten-Kampagnen aus K1 sind bis v1.1 geparkt und erscheinen hier nicht — der Vertrag fuehrt fuer sie derzeit keine Gestalt.

Legt eine Kampagne an. product ist die Weiche im Rumpf: v1 kennt LETTER_STANDARD, den Standardbrief.

Eine Brief-Kampagne ist ein Absender und die Fassung einer Vorlage: templateId nennt die Vorlage, gedruckt wird deren neueste Fassung. Fehlt templateId, gilt die Standardvorlage des Kontos. Eine spaetere Fassung erreicht die Kampagne erst ueber PUT /v1/campaigns/{id}/template-version. Die Kampagne kostet nichts und ist sofort versandbereit — es gibt nichts zu bestellen und auf nichts zu warten.

Eine Kampagne anzulegen braucht nur campaigns:write, auch wenn sie eine Vorlage nennt: sie liest nur, welche Fassung die neueste ist.

Die Kopfzeile Idempotency-Key ist trotzdem Pflicht. Hier fliesst kein Geld, aber jede Kampagne verbraucht eine laufende Nummer aus einer Reihe, die Menschen vorlesen und abtippen; ein Timeout darf daraus keine zwei machen. Derselbe Schluessel ergibt dieselbe Kampagne; die Wiederholung traegt den Status des ersten Aufrufs und die Kopfzeile Idempotent-Replay: true.

Der Absender wird gesetzt, nicht gezaehlt. Er geht durch dieselbe Satzrechnung, die spaeter druckt: sprengt er das Anschriftfeld oder traegt er ein Zeichen, das sich nicht drucken laesst, kommt 422 am Feld sender. Ein Steuerzeichen ist dasselbe 422 in jedem Feld des Absenders, auch im Zusatz und im Namen neben einer Firma, die nicht in der Ruecksendeangabe stehen. Den Text hat schon das Speichern der Fassung geprueft.

Weitere 422: unknown-template (die Vorlage gibt es in diesem Konto nicht) und template-not-active (die Vorlage ist archiviert), beide am Feld templateId.

Nur Kampagnen des eigenen Kontos und der eigenen Umgebung. Eine Kampagne aus der jeweils anderen Umgebung ist ein 404 und kein 403: dass es sie gibt, geht den Aufrufer nichts an.

letter.template nennt Vorlage, Fassung und deren Inhalt, dazu newerVersionAvailable, wenn die Vorlage inzwischen eine neuere Fassung hat.

Aendert, was sich aendern laesst: den Namen zur Wiedererkennung und den Absender. Kennung, Produkt und Umgebung sind unveraenderlich; die Fassung wechselt PUT /v1/campaigns/{id}/template-version.

Auch der Absender geht durch die Satzpruefung. Er steht als Ruecksendeangabe im Fenster, und ein zu langer Firmenname sprengt das Layout — das faellt sonst erst auf dem Kuvertiertisch auf. Ein Steuerzeichen ist in jedem Feld des Absenders 422 am Feld sender.

Haelt ein anderer Vorgang die Kampagne laenger als 5 s, etwa die Annahme eines grossen Versandauftrags: 409 campaign-busy, dann wiederholen.

Stellt die Kampagne auf eine andere Fassung um: eine neuere derselben Vorlage, eine aeltere, oder eine Fassung einer anderen Vorlage des Kontos (templateId). Ohne templateId bleibt es die Vorlage, die die Kampagne schon druckt.

Gedruckt wird die Fassung, auf die die Kampagne beim Stapelbau zeigt — auch fuer Briefe, die vorher angenommen wurden. Damit das die Zusage der Annahme nicht bricht, werden die wartenden Briefe gegen die neue Fassung durchgerechnet, und der Wechsel wird abgelehnt, wenn er einen bezahlten Brief beschaedigen wuerde: der Text laeuft aus der Seite, eine neue Pflichtvariable hat bei den Wartenden keinen Wert, oder eine Variable wird einzeilig und ein Wartender traegt dort einen Zeilenumbruch. Harmlose Wechsel gehen jederzeit durch.

Die Ablehnung ist 422 mit je einem Eintrag in errors[] je Grund, beide am Feld version: queued-item-not-printable und queued-item-missing-value. Genannt werden Anzahlen, keine Briefe. Die Kampagne bleibt dann auf ihrer Fassung; wer trotzdem wechseln will, storniert die wartenden Auftraege.

Werte einer Variable, die die neue Fassung nicht kennt, werden aus den wartenden Briefen entfernt. Eine spaeter wieder erklaerte Variable gleichen Namens ist bei ihnen leer.

Weitere 422: unknown-template (Feld templateId), template-not-active (eine andere, archivierte Vorlage; zwischen den Fassungen ihrer eigenen Vorlage darf eine Kampagne auch dann wechseln, wenn die archiviert ist), unknown-template-version (Feld version) und campaign-not-active fuer eine archivierte oder stornierte Kampagne. Dieselbe Fassung noch einmal ist kein Fehler.

Braucht nur campaigns:write. Haelt ein anderer Vorgang die Kampagne laenger als 5 s, etwa die Annahme eines grossen Versandauftrags: 409 campaign-busy, dann wiederholen.

Legt die Kampagne still: sie nimmt keinen Versandauftrag mehr an und wechselt ihre Fassung nicht mehr. Bereits angenommene Briefe sind davon unberuehrt — sie sind bezahlt und werden gedruckt. Die Vorlage bleibt, wie sie ist.

Das darf der Kunde selbst, anders als bei der Postkarte: eine Kampagne ohne Auflage hat kein bezahltes Material, das jemand erklaeren muesste.

Zweimal archivieren ist derselbe Zustand und kein Fehler. Der Aufruf braucht deshalb keinen Idempotency-Key.

Die Kennung wird nicht frei. Eine Luecke in einer Reihe, die Menschen vorlesen und abtippen, waere schlimmer als eine hohe Zahl.

Haelt ein anderer Vorgang die Kampagne laenger als 5 s, etwa die Annahme eines grossen Versandauftrags: 409 campaign-busy, dann wiederholen.

Die Fassung, die die Kampagne druckt, mit ihrem Absender gesetzt: Werte rein, gesetzte Seite raus. Der Editor holt die Vorschau vom Server und baut das Layout nicht nach — eine zweite Fassung des Satzes waere der Fehler, den niemand bemerkt, bis die Vorschau etwas verspricht, das der Drucker nicht haelt.

Einen Entwurf setzt diese Route nicht; das tut POST /v1/templates/{id}/preview, dort auch mit einem Absender nach Wahl.

Die Seite ist fluechtig. Sie wird nirgends gespeichert, und es gibt keine Einzel-PDF je Brief: das Artefakt der Produktion ist die Stapel-PDF.

Ueber die Kopfzeile Accept waehlt der Aufrufer die Form: application/pdf liefert genau das Artefakt, das spaeter gedruckt wird; image/png liefert dieselbe Seite gerastert. Das PNG entsteht aus der PDF und nicht daneben. Ohne Angabe kommt PDF.

values ist freiwillig, und Pflichtvariablen werden hier nicht erzwungen: die Vorschau zeigt, was gesetzt wuerde. Was fehlt, bleibt leer; nur eine mehrzeilige Variable (TEXT) ohne Wert zeigt einen Mustertext, damit die Seite nicht leer ist. Ein ausdrueckliches "" bleibt leer.

422 an values.<name>: unknown-variable (die Fassung kennt den Namen nicht — sonst waere der Wert stillschweigend wirkungslos), unsupported-character (ein Zeichen, das sich nicht drucken laesst, ein Zeilenumbruch in einer einzeiligen Variable) und body-too-long, wenn sich der Ueberlauf genau einer mehrzeiligen Variable zuschreiben laesst, sonst an values. Passt die Seite nicht, kommt 422 und kein Bild: ein Blatt, das sich nicht drucken laesst, waere genau die Zusage, die diese Route verhindern soll.

Fehler kommen wie ueberall als application/problem+json, siehe das Schema Problem: 400, 401, 403, 404 (Kampagne fehlt, gehoert einem anderen Konto oder liegt in der anderen Umgebung) und 422. Der Vertrag fuehrt nur den Erfolgsfall, weil produces fuer alle Antworten einer Route gilt und die Fehler sonst faelschlich als PDF und PNG ausgewiesen waeren.

Die Auftraege einer Kampagne, neueste zuerst, ohne ihre mailItems. Geblaettert wird mit cursor aus next_cursor der vorigen Seite.

Eine Kampagne, die es in diesem Konto und dieser Umgebung nicht gibt, ist 404 — auch dann, wenn die Liste ohnehin leer waere.

Nimmt 1 bis 5000 Briefe gegen eine Brief-Kampagne an: je Zeile eine Anschrift und die Werte der Vorlage. Bepreist und in LIVE abgebucht wird der Auftrag als Ganzes, unitCredits der geltenden Preisversion mal Anzahl der Zeilen. Abgebucht wird, was zuerst ablaeuft.

Ganz oder gar nicht. Ist eine Zeile nicht verwendbar, wird der ganze Auftrag mit 422 abgelehnt, und errors[] nennt alle unbrauchbaren Zeilen auf einmal, aufsteigend als items.<i> mit dem Code item-not-usable. Der Trockenlauf daneben antwortet in derselben Form. Was nicht zum Schema passt, ist dagegen 400 mit genauem Feldpfad.

Gruende nennt die Antwort nur an einzelnen Werten: direkt hinter items.<i> steht dann je Wert ein Eintrag items.<i>.letter.values.<name> mit unsupported-character (ein Zeichen, das sich nicht drucken laesst, ein Zeilenumbruch in einer einzeiligen Variable) oder body-too-long (der Wert treibt den Brief aus der Seite). Anschrift, Sperrliste, fehlender Pflichtwert und unbekannte Variable bleiben ohne Grund. Hoechstens 5000 solcher Wertbefunde je Antwort.

Die Kopfzeile Idempotency-Key ist Pflicht: derselbe Schluessel mit demselben Rumpf ergibt denselben Auftrag und bucht kein zweites Mal; die Wiederholung traegt den Status des ersten Aufrufs und Idempotent-Replay: true. Nach einer Ablehnung ist der Schluessel wieder frei:

• 402 insufficient-funds: es fehlen Credits. Aufladen und mit demselben Schluessel wiederholen.
• 409 campaign-changed: Fassung oder Absender haben sich geaendert, waehrend der Auftrag geprueft wurde. Mit demselben Schluessel wiederholen; geprueft wird dann gegen den neuen Stand.
• 409 campaign-busy: ein anderer Vorgang haelt die Kampagne laenger als 5 s, etwa ein Fassungswechsel. Mit demselben Schluessel wiederholen.

In TEST wird alles geprueft und angelegt, aber nie gebucht und nie gedruckt. Der Rumpf darf bis zu 16 MiB gross sein (413).

Der echte Aufruf ohne Wirkung: dieselbe Pruefung wie die Annahme, aber nichts wird angelegt, nichts gebucht, und es braucht keinen Idempotency-Key. Der Bereich ist trotzdem shipments:write, weil die Antwort sagt, was die Annahme taete.

Antwortet immer 200 mit dem Preis, auch wenn der Auftrag abgelehnt wuerde. rejections nennt dieselben Codes wie errors[] der Annahme, unbrauchbare Zeilen als items.<i>, Gruende nur an einzelnen Werten als items.<i>.letter.values.<name> wie bei der Annahme. Fehlendes Guthaben ist keine Ablehnung, nur sufficientFunds: false. balanceCredits steht nur fuer Sitzungen und Schluessel mit balance:read darin, sonst null.

Eine Momentaufnahme. Sperrliste, Preis und Vorlage koennen sich bis zur Annahme aendern; verbindlich ist erst die Annahme.

Alle Auftraege des Kontos in der Umgebung des Aufrufers, ueber alle Kampagnen, neueste zuerst, ohne ihre mailItems. Filter gibt es heute keine.

Der Beleg, wie ihn die Annahme zurueckgegeben hat, mit dem heutigen Status. Die mailItems stehen unter /v1/shipments/{id}/items.

Die Stuecke in der Reihenfolge, in der sie eingereicht wurden, mit Anschrift und Werten. index ist dieselbe Zahl wie items.<i> einer Ablehnung. Geblaettert wird mit cursor aus next_cursor.

Nach Ablauf der Loeschfrist wird die Liste geleert; itemCount bleibt.

Storniert den ganzen Auftrag, solange er auf QUEUED wartet. Ist er einem Stapel zugeteilt, ist er auf dem Weg zum Druck und laesst sich nicht mehr zurueckholen: 422 shipment-not-cancellable. Einzelne mailItems lassen sich nicht stornieren.

In LIVE kommt der volle Betrag zurueck, sichtbar als refundedCredits und als SHIPMENT_REFUND im Kontoauszug. Die Credits gehen in die Posten zurueck, aus denen sie kamen, mit deren Ablauf; ist einer inzwischen abgelaufen, verfaellt der Teil sofort wieder und steht als CREDIT_EXPIRY im Auszug. Ein Auftrag von vor 3.0.0 wird in Cent gutgeschrieben (legacyRefundedCents). Ein schon stornierter Auftrag kommt unveraendert zurueck und wird nicht ein zweites Mal gutgeschrieben. Dieser Aufruf braucht deshalb keinen Idempotency-Key: er ist von sich aus wiederholbar.

Aendert sich der Auftrag waehrend des Aufrufs, etwa weil er gerade einem Stapel zugeteilt wird, kommt 409 mit demselben Code; dann den Auftrag neu lesen.

Neueste zuerst. Globale Eintraege des Betreibers sind daran zu erkennen, dass ihr scope GLOBAL ist.

Verglichen wird auf der normalisierten Anschrift: Leerraum zusammengezogen, klein geschrieben. Ausdruecklich ohne Abkuerzungsaufloesung — "Musterstr. 1" und "Musterstrasse 1" sind zwei Eintraege. Wer sicher sperren will, sperrt die Schreibweise, die er auch versendet.

Derselbe Empfaenger ein zweites Mal ergibt denselben Eintrag und 200 statt 201.

Nur eigene Eintraege. Eine globale Sperre hebt allein der Betreiber auf, und das ist der Punkt an ihr.

Die verfuegbaren Credits und der naechste Ablauf.

balanceCredits zaehlt nur, was jetzt noch gilt. Ein Credit, dessen Ablauf erreicht ist, zaehlt nicht mehr mit, auch wenn sein Verfall im Kontoauszug erst etwas spaeter als CREDIT_EXPIRY erscheint.

Neueste zuerst. Jede Buchung fuehrt den Kontostand mit, den sie hinterlassen hat: balanceAfterCredits. Zwei aufeinanderfolgende Buchungen in Credits passen immer zusammen; geblaettert wird ueber die Buchungsnummer und nicht ueber die Uhrzeit.

Buchungen von vor 3.0.0 stehen weiter da, in Cent (legacy*), als eigene Kette neben der in Credits. Umgerechnet wird nichts.

Versandauftraege in TEST erscheinen nicht, sie kosten nichts.

Die Posten mit verfuegbarem Rest, was zuerst ablaeuft zuerst. Verbraucht wird ebenfalls nach dem Ablauf, bei gleichem Ablauf aber zuerst der aeltere Posten (acquiredAt); die Liste ordnet einen solchen Gleichstand nur nach id. Zusammen ergeben ihre Reste balanceCredits aus GET /v1/balance.

Ein verbrauchter oder abgelaufener Posten erscheint hier nicht mehr; seine Geschichte steht im Kontoauszug.