Guides
Use signed webhooks for completed scan notifications
Configure a public HTTPS target to receive a signed session.completed notification after a DropRFID scan session finishes.
Webhooks are useful when another system should learn that a DropRFID scan session has completed. The important boundary is timing: a signed session.completed event is sent after completion. It is a notification and reconciliation path, not a synchronous machine-control loop.
Configure a reachable target
Use a public HTTPS endpoint that your receiving service controls. Production webhook targets cannot be localhost or private/internal addresses. If the destination system lives on a private network, place a secured public ingress or relay in front of it rather than claiming DropRFID posts directly to the internal host.
The setup recording in this article is mock-backed. It uses a synthetic target and signing secret, and the successful test delivery is not a live customer event. Never copy a secret from a screenshot or publish a real endpoint.
Verify, store, and retry safely
Keep the webhook secret server-side. Verify the signature before accepting the payload, validate the event type and schema, and record an idempotency key or event identifier so a retry does not create a duplicate downstream action. Return an appropriate success response only after the receiver has safely accepted the event.
Delivery can fail and be retried. Design the handler to tolerate duplicate delivery and temporary downstream outages. Log enough context to investigate without logging API keys, signing secrets, credentials, or private customer data.
The event carries a completed-session snapshot. It can notify a warehouse or operations service, reconcile a record, or start a follow-up process. It does not provide a public endpoint for an external AI or machine to create a scanner session, ingest live RFID reads, or complete the session.
Webhook or API?
The choice is often “when should my system retrieve?” versus “tell my system when the session finishes.” Use the supported public API when your system chooses when to read session or SKU/order data. Use a signed webhook when a post-completion event is the useful trigger. Many integrations use both: the webhook wakes the downstream workflow, and an authenticated API read retrieves the details it needs.
The exact payload mapping and downstream action remain configuration work. Test with sample events, signature failures, retries, and malformed input before enabling production behavior. Keep a manual review path for exceptions.
The goal is dependable handoff, not magical automation: a verified event, a reachable receiver, and a clear owner for what happens next.
Before enabling a production target, run a small test matrix: valid signature, invalid signature, duplicate event, delayed response, temporary outage, and an unexpected payload field. Review the receiver’s logs and retry behavior. This preparation turns a configuration screen into an integration that an operations team can actually trust.
Record the agreed event owner and escalation path so a failed delivery has a clear next step.
That small operational detail is often what makes an integration maintainable after launch.
