Listings
Public summarylisting.published
A listing became visible to shoppers.
v1 ·Stable
listing.updated
Listed price or details changed.
v1 ·Stable
listing.withdrawn
A listing was removed from sale.
v1 ·Stable
Webhooks
Webhooks
Learn how approved DriverXtra integrations may deliver event notifications to a callback you control.
Event notifications
sent to a callback you control
Signed deliveries
verify before you process
Idempotent receivers
expect duplicates and delays
How delivery works
From event to endpoint — with clear controls
1. Event occurs
Something changes in an approved product area.
2. Authorized subscription
Your organization is approved for that event family and environment.
3. Validated callback
Your HTTPS endpoint passed ownership and safety checks.
4. Signed attempt
A delivery attempt is signed and sent.
5. You acknowledge
Your receiver verifies, records and responds.
Event catalog
Approved event families
Only explicitly approved public summaries are shown. Restricted families don't reveal their event names.
Inventory feeds
Public summaryfeed.run.completed
A feed import run finished.
v1 ·Beta
feed.run.failed
A feed import run stopped with errors.
v1 ·Beta
Envelope
What a notification looks like
Annotated illustrative specimen with synthetic values. Field names are not a production contract.
- 1
Event ID
Stable for the event. The same event may arrive in more than one attempt — deduplicate on this.
- 2
Type
The approved event type, from the published catalog.
- 3
Version
The schema version. Breaking changes get a new version.
- 4
Time
When the event was created — not when it was delivered.
- 5
Data
A minimal payload. Fetch details from the API if you need more.
Delivery semantics
Design your receiver for real-world delivery
Duplicates, delays and order
Your receiver should handle duplicate, delayed or out-of-order notifications unless a published contract states otherwise.
- Deduplicate on the event ID
- Don't assume events arrive in order
- Acknowledge quickly, process asynchronously
Acknowledgement
Transport receipt and business processing are separate. The accepted response class and timeout are set by the published contract.
- Accepted response
- Not yet published
- Timeout
- Not yet published
Security
Validate the sender before processing an event
- 1
Use HTTPS you control
Use an approved HTTPS callback that your organization controls. Private or unsafe destinations are not permitted.
- 2
Keep the raw body
Verify against the untouched request bytes, before parsing.
- 3
Check key ID and timestamp
Reject stale or unknown keys. The freshness window comes from published guidance.
- 4
Compare signatures safely
Use a constant-time comparison.
- 5
Then process
Only after verification passes.
Subscriptions
How a subscription is set up
Subscriptions depend on program eligibility, your organization and environment scopes. There's no universal self-serve creation.
- 1
Organization
Choose your approved organization
Access-controlled
- 2
Environment
Non-production or production, where provisioned
Access-controlled
- 3
Endpoint
HTTPS callback with ownership checks
Access-controlled
- 4
Events
Eligible event families only
Access-controlled
- 5
Confirm
Reviews and approvals
Access-controlled
Retries, replay & testing
When deliveries fail
Retries and replay
An event can have several delivery attempts. Retry, replay or support timing is not published for this integration. Refer to your approved agreement.
Testing
Test events use synthetic fixtures in a non-production environment, where one has been provisioned for your organization. There's no “Send test” control on this page.
Troubleshooting deliveries
| Symptom | Likely class | Safe next step |
|---|---|---|
| Your endpoint returns errors | Receiver fault | Check your logs using the event ID — never log secrets. |
| Requests time out | Network or slow processing | Acknowledge first, then process asynchronously. |
| Signature check fails | Verification fault | Use the raw body and the correct key ID; check clock skew. |
| Nothing arrives | Subscription or eligibility | Check subscription status, then Platform Status. |
Privacy & versions
Minimal data, governed change
Data minimization
Payloads carry the minimum needed. Sensitive event families need a separate review. Retention is set by policy and your agreement.
Versions and changelog
| Family | Version | Support window |
|---|---|---|
| Listings | v1 | Not yet published |
| Inventory feeds | v1 (beta) | Not yet published |
FAQ
Webhooks questions
Webhooks are an integration pattern in which an approved service sends an event notification to a destination you control. DriverXtra event types and access are available only where officially published and authorized.
Yes. This page and the public event summaries are open to everyone. Subscriptions, secrets and delivery logs need authorized access.
Only the event families shown in the catalog above, at the lifecycle stage shown. Restricted families aren't listed publicly.
No. You can subscribe only to event families your organization is approved for, in environments provisioned for you.
No. A callback must pass ownership and safety checks, and the subscription must be approved, before any delivery is attempted.
HTTPS endpoints that your organization controls. Private, internal or otherwise unsafe destinations are rejected.
Verify the signature against the raw request body, check the key ID and timestamp, and compare in constant time before processing.
No. A signing secret is shown once when it's created. If it's lost, rotate it and update your receiver.
Not unless a published contract says so. Expect duplicates, delays and out-of-order delivery, and deduplicate on the event ID.
No. It only acknowledges receipt. Your own processing and any follow-up calls are separate.
An event can have several delivery attempts. Retry timing isn't published for this integration — refer to your approved agreement.
Replay availability depends on your agreement. There's no public replay control on this page.
Test events use synthetic fixtures in a non-production environment, where one has been provisioned for your organization.
Payloads are minimized and access-controlled. Authorized users can see delivery details for their own organization only.
Accept both the old and the new key during the overlap, switch to the new key ID, then retire the old key.
They summarize recent delivery attempts for your subscription. They describe delivery, not whether your business processing succeeded.
Check Platform Status first, then report a problem from the Developer Hub with the event ID. Never include secrets.
New deliveries stop. Events already in flight may still arrive, so keep your receiver tolerant for a short while.