Status and support

#Platform status

GET /v1/status answers without authentication and tells you whether the platform is healthy before you open a ticket. The components come from the last five-minute health check of the platform; the public status page carries incident history and planned maintenance.

curl https://api.postbuddy.nl/v1/status

{
  "status": "operational",
  "components": [
    { "name": "api", "status": "operational" },
    { "name": "processing", "status": "operational" },
    { "name": "events", "status": "operational" },
    { "name": "redirect", "status": "operational" },
    { "name": "backups", "status": "operational" }
  ],
  "checkedAt": "2026-10-12T09:05:00.000Z",
  "version": "1.4.0",
  "statusPageUrl": "https://status.postbuddy.nl"
}

status is operational, degraded (queues behind, events delayed, a stale backup) or down (no worker, the QR redirect service unreachable). processing covers rendering and the production run steps, events the webhook and event feed publication, redirect the short domain printed in QR codes.

#Planned maintenance

Maintenance windows are announced on the status page and never overlap a production run cutoff. Deploys of the API do not drop in-flight requests; an item accepted with 202 is never lost (it is committed before the answer).

#Getting help

• Quote the X-Request-Id of the failing response; every log line and audit entry carries it.
• Webhook deliveries can be inspected and replayed from the portal (Developers, Webhooks) or with POST /v1/webhooks/{id}/deliveries/{deliveryId}/replay.
• Items that need attention are listed in the portal work queue and through GET /v1/items?filter[status]=NEEDS_ATTENTION.
• Support sessions: when support needs to look at your organisation, an administrator starts a time-boxed session with a reason; your Owners are notified, a banner shows it in the portal and secrets stay hidden during the session.