The Adapter Gateway makes work available to your adapter as events. Your adapter polls GET /external/events and processes each returned event.

Event types

`eventType`	When it fires	What to do
`SUBMIT_EVENT`	A PDX user (or auto-submit) submitted products to your channel	Fetch the submission data, deliver it, report status — see Fetching Submission Data
`AUTHENTICATION_EVENT`	A PDX user connected or re-validated an account on your channel	Validate the credentials against the target system and report the result via `POST /external/authentication`
`CLIENT_CHANNEL_DELETED_EVENT`	A PDX client's connection to your channel was deleted	Clean up any per-client state your adapter or the target system holds

Each event carries eventId, created, clientId, channelId, eventType, acknowledged, and a type-specific data payload (for SUBMIT_EVENT, this includes the submissionId you need for all follow-up calls).

The events endpoint

GET /external/events?limit=10

Parameter	Default	Meaning
`type`	all types	Filter to a single event type
`channelId`	all your channels	Filter to one channel
`clientId`	all clients	Filter to one PDX client
`limit`	`10`	Max events per response; maximum allowed is `100`
`startingAfter`	—	An `eventId`; returns only events created after that event
`autoAck`	`true`	Acknowledge all returned events as part of the read
`returnAck`	`false`	Also include already-acknowledged events in the response

Events are returned oldest first. Events are retained for 30 days after creation, acknowledged or not; do not treat the event stream as a permanent audit log.

Acknowledgment

With the default autoAck=true, events are acknowledged as part of the poll: each poll returns the batch of new events, and the next poll returns only what arrived since. This is the standard pattern — it is also how the Adapter SDK consumes events — and the recommended starting point. Because an event returned to you will not be returned again, make sure your adapter processes every event of a fetched batch, and design processing so a batch can be safely reprocessed if your adapter restarts mid-way.

Manual acknowledgment

For finer-grained control, poll with autoAck=false and acknowledge each event individually after processing it:

PUT /external/events/{eventId}

Unacknowledged events are returned again on every poll (with the default returnAck=false) until they are acknowledged, so events are never dropped if the adapter fails mid-batch. The flip side is that processing must be idempotent — you may see the same event more than once, so make delivery to the target system safe to repeat (for example, key it on submissionId).

Polling cadence

There is no server-side push, long-polling, or webhook mechanism; the polling interval is yours to choose. As a starting point:

Poll every 30–60 seconds for production adapters. Submissions are not latency-sensitive at sub-second granularity, and PDX users see submission progress through the status you report, not through polling speed.
Use limit=100 and loop until you receive an empty (or short) page when draining a backlog.
Add jitter and back off on errors — on 5xx responses, wait before retrying rather than tight-looping.

Pagination

startingAfter is a cursor based on the event's creation time: pass the last eventId of the previous page to get the next page. For normal operation you rarely need it — polling with a limit naturally pages through the backlog as events are acknowledged. Use startingAfter together with returnAck=true when you need to re-read history, for example when backfilling after a bug.