This page is the dictionary and the bulk tool: which events exist as Portal-trackable
events, which identifier each carries so you can match it to your own records, how far back the
log goes, and how to replay a whole window of failures at once.
Which event types does the Portal track?
Seven. This is the exact set the Event Type filter offers, and the set searched when you leave that filter empty:
Two points that save wasted searching:
- There is exactly one chargeback event. Every chargeback creation and every status change
on the case arrives as
CHARGEBACK_NOTIFICATION. There is no separate alert event and no separate chargeback-refund event to subscribe to. - The value in the
eventTypecolumn is the value above, so what you read in the Portal is what you match on in your own code. The friendly label is display only.
How do I match a webhook back to my own order?
Every record carries one Order ID, and which identifier that is depends on the event. This is the crosswalk:
The chargeback row is the one that surprises people, so state it plainly: searching the log
by your original payment order number will not find a chargeback notification. The Order ID
column there is the case’s own identifier, not your order. Open the record and read
originalOrderId from the request body. The same caution applies in reverse — do not use the
chargeback log’s Order ID as a key in your own system.
For subscriptions, note that an upgrade or downgrade produces a new subscription ID, so a
SUBSCRIPTION_CHANGE_NOTIFICATION will not match on the subscription ID you had before the
change. Read the original ID from the payload if you key on it.
Which of these can I subscribe to, and where does the URL come from?
Only two callback URLs are yours to set in the Portal; the rest travel with the API call that created the object. Nothing on the webhook log page changes a URL — that page is read-only by design.
Configuring the Portal-side URLs is covered in
Portal Self-Service Security Configuration. If an
event produced no log record at all, the usual cause is that no URL was resolved — see
Webhook Event Log & Manual Resend.
How far back does the webhook log go?
90 days. The page says so in a banner, the date picker will not let you select a day earlier than 90 days ago, and Retry by Date is bounded by the same window. For anything older, query the object itself through its inquiry API rather than looking for the notification. Two related boundaries:- The log starts at the point the feature went live. Older notifications are not backfilled, so an empty result for a very old transaction is expected rather than diagnostic.
- The list is sorted by Submission Time, newest first, by default.
Can I replay a whole window of failures at once?
Yes — Retry by Date, which exists for exactly the case where your endpoint was down for a period and you want the failures from that window re-driven without clicking them one by one.
Only failed records are eligible — successful and in-flight records are never included, so you
cannot accidentally re-deliver something your endpoint already accepted.
How many can one batch resend?
At most 50 records per request. This applies to Retry by Date and to multi-select resend alike, and it is enforced on both sides rather than being a UI hint. What that means in practice:
The batch is not silently truncated to the first 50 — an over-limit range is refused
outright. That is deliberate: a truncated batch would leave you believing a window had been
replayed when most of it had not. For a large backlog, work through it in slices — by event
type first, since that usually splits the window along the lines your incident actually
followed.
What do I get back after a batch resend?
A per-record result, summarised as counts rather than a single pass/fail:
“Succeeded” means your endpoint accepted the delivery on this attempt — the batch reports the
real delivery outcome, not merely that the request was queued. So a batch that comes back all
failed is telling you your endpoint is still not accepting the payload; fix it before replaying
again.
Records whose state changed between the estimate and the send — one that succeeded on an
automatic retry in the meantime, for instance — are counted in the failed tally rather than
resent, because they are no longer eligible.
Does a manual or batch resend use up my automatic retries?
Yes — and this is worth knowing before you replay a window against an endpoint you have not actually fixed. A resend goes down the same delivery path as an automatic attempt. If your endpoint does not accept it, the attempt is counted against the record’s retry budget just like an automatic one, and a next automatic retry is scheduled only while budget remains. Once the budget is exhausted the record is finally failed: Next Retry shows— and no further automatic
attempt will be made.
The practical rule: verify your endpoint first, then replay. Replaying against a still-broken
endpoint burns attempts that were otherwise still scheduled to fire on their own.
What does the Portal consider a “Failed” record?
Failed covers both records that have finally failed and records that failed this time but are
still in the automatic retry queue. The two are distinguished by the Next Retry column
rather than by the status:
This matters for Retry by Date: the estimate counts both kinds of failed record, so a window
you replay may include records that would have recovered on their own.
Why does a successful record show no response from my endpoint?
Because the Portal derives the display for a delivered record rather than storing what your server sent. A successful record shows a200 HTTP Response and a success body because that
is what “successful” means — a delivery only counts as successful when your endpoint returns
HTTP 200 and a body of {"message":"success"}, per
Webhook overview.
Real captured detail exists only on failed records, where the failure summary your endpoint
returned — or the transport error — is shown. So when you are debugging, the failed records are
the informative ones; there is nothing extra hiding behind the successful ones.
Will resending create a second row in the log?
No. There is one record per event per business object — the same payment order’s payment notification is one row for its whole life. A resend updates that row’s status, response and attempt count in place; it does not add a row. The Notify Count in the detail view is your attempt history. That is also why you cannot use row counts to measure delivery volume, and why a resent record loses its previous failure summary once a later attempt overwrites it.If a record you expect is missing entirely rather than failed, start from Webhook Event Log & Manual Resend — a missing record almost always means no callback URL was resolved, which resending cannot fix.