API logs

API logs help you operate your integration. They show which requests PostPal received and how they were processed.

You can find:

• Time and status of a request.
• Error hints for validation or processing problems.
• In the detail view: the submitted and received data (e.g. recipient and sender address, content, QR codes). Sensitive values such as passwords remain redacted there too.
• For status 429 (rate limit exceeded): the current limit, how many requests were left in the window, and how many seconds until a retry is possible.
• For postcard requests from API flows: a front and back preview once it has been generated. You can download the PDF and view the pages enlarged.
• For requests from API flows: the Mailing Status. Not Started means that no mailing has been assigned yet, In Progress that the mailing is being created, Done that the mailing has been commissioned for printing, and Excluded that the request is not included in the mailing.

The preview is based on the data you submitted with the request. It is a diagnostic tool, not a print approval: formatting, address validation and voucher assignment can still change the final print. The preview is removed after 60 days for data-protection reasons.

Filtering the list: above the list, the Filter button opens a panel with every filter; the number next to it shows how many are currently active. You can filter by:

• Zeitraum (date range) — defaults to All time, or you can choose a quick range (last 24 hours, last 7 days, last 30 days) or Benutzerdefiniert with your own start and end point made up of date and time.
• Umgebung (environment) — test or live.
• Status — the HTTP status PostPal responded with, e.g. 422 or 429.
• Token — the API token the request authenticated with.
• Flow — the API flow the request belongs to.

The filters combine. They take effect on Anwenden, and whatever is in force then appears as a chip above the list. Remove an individual filter via the X on its chip, or clear them all at once with Zurücksetzen in the panel. The active filtering is part of the address bar, so a filtered view can be bookmarked or passed on to a colleague.

The date range uses the time zone the list displays timestamps in (Europe/Berlin), not UTC, so the filter matches what you read on screen. Both ends are inclusive: an end point of 14:20 still includes requests from that minute, and an end date without a time covers the whole day.

A selection you made for removing or restoring requests survives paging, but not a filter change: after paging you are still working through the same result list, after a filter change it is a different one. Every filter change therefore starts with an empty selection.

Removing requests from a planned mailing: when your integration triggered a postcard that should not go out — a test run against live, a duplicate order, a cancelled purchase — you do not have to stop the entire mailing. Select the affected requests in the list (individually or across pages) and remove them. They will then be neither printed nor sent, but stay visible as a log entry with the Removed label, so the history of your integration stays complete.

This only works while the mailing has not been created yet. Requests that are already part of a mailing stay unchanged — by that point they are in print preparation. The same applies to test requests and their test run: once the test run has been executed, they can no longer be removed. A test request is never printed or sent either way.

Restoring: anything removed by mistake can be taken back the same way; the request returns to pending. A live request is then printed and sent as normal; a test request rejoins the next test run and — like every test request — is neither printed nor sent. Three things end that option for good: the mailing has since been created or the test run has since been executed, the related API flow was deleted, or the 60-day retention period has passed and the request's recipient data has been anonymized. In all three cases PostPal tells you which reason applies. Simply sending the request again is not a substitute — it is recognised as a duplicate and answered with 409. Once the retention period has passed, only a new request with a new request ID remains.

Mind the effect on the sendout date: an API flow only creates its mailing once a configured minimum is reached. If you remove enough requests to drop below that threshold, the mailing moves to the next window in which it is met again. The confirmation dialog points this out before you confirm. For more on the states, see entry processing & batching.

Retention of personal data: the stored payload is anonymised automatically once the retention window has passed. Recipient name and street are replaced with [anonymisiert] after 60 days. Card content and QR targets follow as soon as the print run for the related mailing is finally complete — at the earliest also after 60 days. Structure, status, error messages, your own sender address and the recipient's postcode, city and country are kept, so the logs remain useful for diagnosis. For affected requests, the detail view shows you the date of anonymisation.

Logs are meant for diagnosis. Business-critical reporting should always be based on the related domain records (campaign, postcard, flow), not on the logs.