API-Logs

API-Logs helfen beim Betrieb deiner Integration. Sie zeigen, welche Requests PostPal empfangen hat und wie sie verarbeitet wurden.

Du findest dort:

• Zeitpunkt und Status eines Requests.
• Fehlerhinweise bei Validierungs- oder Verarbeitungsproblemen.
• In der Detailansicht: die übermittelten und empfangenen Daten (z. B. Empfänger- und Absenderadresse, Inhalte, QR-Codes). Sensible Werte wie Passwörter werden auch dort weiterhin redigiert.
• Bei Status 429 (Rate-Limit überschritten): das aktuelle Limit, wie viele Requests im Zeitfenster noch übrig waren und nach wie vielen Sekunden ein erneuter Versuch möglich ist.
• Für Postkarten-Requests aus API-Flows: eine Vorschau der Vorder- und Rückseite, sobald sie erstellt wurde. Du kannst die PDF herunterladen und die Seiten vergrößert ansehen.
• Für Requests aus API-Flows: den Mailing Status. Not Started bedeutet, dass noch kein Mailing zugeordnet ist, In Progress, dass das Mailing erstellt wird, Done, dass das Mailing zum Druck gegeben wurde, und Excluded, dass der Request nicht im Mailing enthalten ist.

Die Vorschau basiert auf den Daten, die du mit diesem Request übermittelt hast. Sie ist ein Diagnosewerkzeug, keine Druckfreigabe: Formatierung, Adressprüfung und Gutschein-Zuweisung können den finalen Druck noch verändern. Nach 60 Tagen wird die Vorschau aus Datenschutzgründen gelöscht.

Liste filtern: Über der Liste öffnet die Schaltfläche Filter ein Panel mit allen Filtern; die Zahl daneben zeigt, wie viele davon gerade aktiv sind. Filtern kannst du nach:

• Zeitraum — standardmäßig Gesamter Zeitraum, alternativ ein Schnellfilter (letzte 24 Stunden, letzte 7 Tage, letzte 30 Tage) oder Benutzerdefiniert mit eigenem Von- und Bis-Zeitpunkt aus Datum und Uhrzeit.
• Umgebung — Test oder Live.
• Status — der HTTP-Status, mit dem PostPal geantwortet hat, z. B. 422 oder 429.
• Token — der API-Token, mit dem der Request authentifiziert wurde.
• Flow — der API-Flow, zu dem der Request gehört.

Die Filter wirken zusammen: gesetzt werden sie erst mit Anwenden, und was gerade greift, steht danach als Chip über der Liste. Einzelne Filter nimmst du über das X am jeweiligen Chip wieder heraus, Zurücksetzen im Panel leert alle auf einmal. Die aktive Filterung steht in der Adresszeile — eine gefilterte Ansicht kannst du also als Lesezeichen speichern oder an Kolleginnen und Kollegen weitergeben.

Beim Zeitraum gilt die Zeitzone, in der die Liste die Zeitpunkte anzeigt (Europe/Berlin), nicht UTC — der Filter passt also zu dem, was du auf dem Bildschirm liest. Beide Enden zählen mit: Bis = 14:20 schließt Requests aus dieser Minute noch ein, und ein Bis-Datum ohne Uhrzeit umfasst den ganzen Tag.

Eine Auswahl, die du für das Entfernen oder Wiederaufnehmen getroffen hast, überlebt das Blättern, aber nicht eine Filteränderung: Nach dem Blättern arbeitest du dieselbe Ergebnisliste weiter durch, nach einer Filteränderung eine andere. Die Auswahl startet deshalb bei jeder Filteränderung wieder leer.

Requests aus einer geplanten Aussendung entfernen: Wenn deine Integration eine Postkarte ausgelöst hat, die nicht raus soll — ein Testlauf gegen Live, ein doppelter Auftrag, eine stornierte Bestellung — musst du nicht die ganze Aussendung anhalten. Wähle die betroffenen Requests in der Liste aus (einzeln oder seitenübergreifend) und entferne sie. Sie werden dann nicht gedruckt und nicht versendet, bleiben aber als Protokolleintrag mit der Kennzeichnung Entfernt sichtbar, damit die Historie deiner Integration vollständig bleibt.

Das geht nur, solange die Aussendung noch nicht erstellt wurde. Requests, die bereits Teil einer Aussendung sind, bleiben unverändert — sie sind zu diesem Zeitpunkt schon in der Druckvorbereitung. Für Test-Requests gilt dasselbe gegenüber dem Testlauf: Sobald der Testlauf ausgeführt wurde, lassen sie sich nicht mehr entfernen. Gedruckt oder versendet wird ein Test-Request aber ohnehin nie.

Wieder aufnehmen: Versehentlich Entferntes holst du auf demselben Weg zurück; der Request wandert dann zurück nach pending. Ein Live-Request wird damit ganz normal gedruckt und versendet, ein Test-Request kehrt in den nächsten Testlauf zurück und wird — wie jeder Test-Request — weder gedruckt noch versendet. Drei Dinge beenden diese Möglichkeit endgültig: die Aussendung wurde inzwischen erstellt beziehungsweise der Testlauf inzwischen ausgeführt, der zugehörige API-Flow wurde gelöscht, oder die 60-tägige Aufbewahrungsfrist ist abgelaufen und die Empfängerdaten des Requests sind anonymisiert. In allen drei Fällen sagt dir PostPal, welcher der Gründe zutrifft. Den Request einfach noch einmal zu senden ist kein Ersatz — er wird als Duplikat erkannt und mit 409 beantwortet. Nach Ablauf der Aufbewahrungsfrist bleibt nur ein neuer Request mit einer neuen Request-ID.

Beachte die Auswirkung auf den Versandzeitpunkt: Ein API-Flow erstellt seine Aussendung erst ab einer eingestellten Mindestmenge. Entfernst du so viele Requests, dass diese Schwelle unterschritten wird, verschiebt sich die Aussendung auf das nächste Fenster, in dem sie wieder erreicht wird. Der Bestätigungsdialog weist dich darauf hin, bevor du bestätigst. Mehr zu den Zuständen findest du unter Entry-Verarbeitung & Batching.

Aufbewahrung personenbezogener Daten: Der gespeicherte Payload wird nach Ablauf der Aufbewahrungsfrist automatisch anonymisiert. Empfängername und Straße werden nach 60 Tagen durch [anonymisiert] ersetzt. Karteninhalte und QR-Ziele folgen, sobald der Druck des zugehörigen Mailings endgültig abgeschlossen ist — frühestens ebenfalls nach 60 Tagen. Erhalten bleiben Struktur, Status, Fehlermeldungen, deine eigene Absenderadresse sowie PLZ, Ort und Land des Empfängers, damit die Logs für die Diagnose brauchbar bleiben. Die Detailansicht zeigt dir bei betroffenen Requests das Datum der Anonymisierung an.

Logs sind für Diagnose gedacht. Geschäftskritische Auswertungen sollten immer auf den jeweiligen Fachobjekten (Kampagne, Postkarte, Flow) basieren, nicht auf den Logs.