Event-driven integrations (order status, RFQ updates, payment state) should use webhooks instead of tight polling — the same model used by Crisp and Stripe.
Tradeics Web Hooks delivery is rolling out with Platform. Use this guide to design receivers now, and poll only as a temporary bridge.
Design your receiver first
- Expose an HTTPS endpoint your edge can verify (TLS required).
- Accept
POSTwith a JSON body; respond2xxquickly (under a few seconds). - Process asynchronously — enqueue work, then acknowledge.
- Treat deliveries as at-least-once: dedupe on event id /
external_id. - Verify signatures when Tradeics publishes a signing secret (HMAC over the raw body).
Event categories (planned)
| Domain | Example reasons to subscribe |
|---|---|
| Marketplace / network | Catalog publish, partner invites, order state |
| Source-to-pay | RFQ open / award, PO approved, invoice posted |
| Finance | Payment captured, wallet movement, settlement batch |
| Platform | Membership / permission changes |
Exact event names will ship in a Web Hooks reference when live. Prefer durable event ids over brittle type strings in your storage key.
Security checklist
- Rotating secrets: support dual secrets during rotation windows.
- Reject unsigned or stale timestamps.
- Never expose receiver URLs without auth or signature checks.
- Log delivery ids for support — include them when contacting us.
Until webhooks ship
- Poll with pagination and respectful rate limits.
- Prefer ETag /
updated_sincefilters when a route exposes them. - Agent automations via MCP can watch for change interactively, but are not a substitute for reliable delivery to your ERP.