Error notifications
Operational-monitoring inbox for the partner: failed scrapes, missing credentials, throttled API quotas.
Operational-monitoring inbox for the partner: failed scrapes, missing credentials, throttled API quotas. Notifications can be listed (filtered by status bucket), inspected in detail, annotated with notes, bulk-transitioned, and re-emailed to the on-call admin.
Prerequisites
- A bearer token in the
Authorizationheader. Any endpoint that needs no token says so on its own page. - The id of each record the call targets. Every endpoint page lists the ids it needs.
Errors
| Status | Meaning |
|---|---|
401 | The bearer token is missing, expired or invalid |
403 | The token is valid but the record sits outside your account |
422 | The request failed validation — the response names the fields |
500 | Unexpected server error |
Individual endpoints may return more; each page lists its own.
Endpoints
GET — Get a paginated, sortable, searchable list of the partner's error/monitoring notifications, filtered by lifecycle state (open / acknowledged / resolved).
GET — Get the full raw record of a single error notification and, if it belongs to the caller's company and is still unread, mark it as notified.
GET — Get a paginated list of notes attached to a given error notification, newest-updated first.
POST — Bulk-updates the lifecycle status of one or more error notifications, marking them acknowledged or resolved.
POST — Send the error-notification alert email, either to the store's configured response-posting error recipients (email_to=admin) or to a custom address (email_to=other).
Updated 11 days ago