Getting Started > Webhook Delivery Logs

Webhook Delivery Logs (Push Log)

Last Updated: 2026-07-02

Overview

The Push Log is the MallPlus console viewer for webhook delivery history. Every attempt the webhook dispatcher makes to your callback URL — whether it succeeds or fails — is recorded as a row, so you can debug failed deliveries, inspect payloads, and confirm timing without raising a support ticket.

Both live and sandbox deliveries are recorded in the same log. Open the Push Log from the console sidebar under Tools → Push Log. Each row shows the delivery's outcome at a glance; click a row to expand the full detail (callback URL, HTTP status, response time, error message, and the raw payload).

Self-service debugging: The Push Log exists so you can answer "did my endpoint receive this event, and what did it return?" on your own. Pair it with the Push Mechanism guide for the underlying delivery semantics (signing, headers, retries).

How to Use

Sign in to the Push Log page (admin or partner session).
Select a Partner ID (your app) from the dropdown — this is required and scopes the log to that app's deliveries only.
Optionally narrow the result with the filters (event type, send result, keyword, date range), then click Search.
Click any row to expand the delivery detail — callback URL, HTTP status, response time, error message, and the raw JSON payload that was sent.

The list defaults to showing failures only (Send Result = Fail), because the most common reason to open the Push Log is to debug a missed delivery. Switch the Send Result filter to All or Success to see successful deliveries too.

Columns

The Push Log table shows four columns per delivery:

Column	Description
Send Time	When the delivery attempt occurred, in UTC+08:00. Newest first.
Push Mechanism	The event type label (e.g. Order Shipped) fired to your endpoint — the human-readable form of the `X-MallPlus-Event` header.
Send Result	Outcome of the delivery attempt: Success (endpoint returned 2xx) or Fail (non-2xx, timeout, or TLS/connection error).
Push Details	The callback URL the payload was POSTed to (truncated in the list; full URL in the expanded row). Click the row to expand the complete delivery detail.

Filters

The filter panel lets you narrow the delivery history:

Filter	Effect
Partner ID	Required. Scopes the log to one app's deliveries.
Push Mechanism	Event type (e.g. `order.shipped`). Selects from the full catalogue of 19 subscribable events.
Send Result	All, Success, or Fail. Defaults to Fail to surface problems first.
From / To	Date-range window. Defaults to the last 24 hours. Windows wider than 90 days are silently capped to the 90 days from your From date (no error is returned), so keep the range within 90 days to be sure you are searching the period you intend.
Keywords	Free-text search across the callback URL and error message.

The Push Mechanism dropdown lists every subscribable event. The full set of 19 event types (orders, fulfillment, inventory, catalog, and returns events) is documented in the Push Mechanism → Event Types section.

Delivery Detail

Click any row to expand the full delivery record. The expanded panel shows:

Callback URL — the full HTTPS endpoint the payload was POSTed to.
HTTP Status — the response code your endpoint returned (e.g. 200, 500, 0 for a connection/TLS/timeout failure).
Response Time — round-trip latency in milliseconds.
Error — shown only on failures; the dispatcher's reason for treating the attempt as failed (e.g. SSRF check failed, Exceeded redirect follows, a timeout message, or the HTTP status text).
Payload — the raw JSON body that was sent, including the event, eventId, deliveryId, timestamp, and data envelope. Large payloads are truncated at 64 KB.

The eventId is stable across retries (use it to dedup); the deliveryId changes per attempt. See Retries & Idempotency for the full semantics.

Delivery Results

Each attempt resolves to one of two results in the Push Log:

Result	Meaning
Success	Your endpoint returned a `2xx` status within the 30-second timeout. The delivery is complete and will not be retried.
Fail	Your endpoint returned non-2xx, timed out (30 s), or the connection/TLS failed. The dispatcher retries failed deliveries up to 3 attempts with exponential backoff (4s → 16s → 64s). Each retry attempt appears as its own row, so a single logical event may show several rows until one succeeds.

Because delivery is at-least-once, your handler must be idempotent — dedup by eventId so processing the same event twice (on a retry or a replay) has no side-effect. Full retry and dedup guidance is in the Push Mechanism guide.

Retention

Push Log rows are retained for 90 days, after which a daily cleanup job deletes them. The queryable window in the filter panel is also capped at 90 days per query: a window wider than 90 days is silently shortened to the 90 days from your From date (the response still returns 200 OK, so check your window if a query seems to miss older rows). If you need a longer history, export the rows you need before they age out — MallPlus does not archive delivery logs beyond the retention window.

Troubleshooting

No rows appear — confirm a Partner ID is selected and widen the date range. The default Send Result filter is Fail; switch to All if you expect successful deliveries.
HTTP Status 0 — the dispatcher could not establish a connection. Common causes: the callback URL is unreachable, the TLS handshake failed, or the request exceeded the 30-second timeout. As an SSRF safeguard the dispatcher resolves the callback host and blocks private and reserved IP ranges (RFC 1918 like 10.x / 192.168.x, loopback, link-local, and cloud metadata addresses); public hosts, including tunnel services such as ngrok, are allowed.
HTTP Status 500 / 502 / 503 / non-2xx — your endpoint returned an error. Inspect the Error field and the Payload in the expanded row, fix your handler, then re-drive the event from the sandbox.
Signature mismatch on your side — verify you are computing the HMAC over the raw request body (before any JSON middleware re-serialises it). See Signature Verification.