Guides
API or webhook? Choose the right delivery pattern
How to choose between retrieving completed scan-session data with the API and receiving a signed completion notification by webhook.
API and webhook integrations solve related but different timing problems. Use the DropRFID HTTP API when your system should choose when to retrieve data. Use a signed webhook when your system should be notified after a scan session completes.
API: your system pulls
An API request starts with your service. It authenticates with an organization API key, calls a documented endpoint, and receives the resource representation it is allowed to read or change. This model is useful when a scheduled job, operator action, or reconciliation process controls the timing.
The public REST API can read sessions, manage SKUs, manage orders, and work with routines. It does not provide a public endpoint for creating a scanner session, ingesting live RFID reads, or completing that session. Do not design an integration around an endpoint that is not documented.
Webhook: DropRFID notifies after completion
A signed session.completed webhook is an after-completion delivery path. When a scan session is complete, DropRFID can send the completed session snapshot to a configured destination. Your service should verify the signature, handle retries safely, and use an idempotency strategy so duplicate deliveries do not create duplicate work.
The webhook is not a synchronous control loop and should not make a machine’s immediate accept/reject decision depend on delivery. Production targets must be publicly reachable over HTTPS; a private warehouse or airport LAN needs a secured public ingress or relay in front of it.
Use either—or both
Many systems combine the patterns. A webhook can wake a downstream process, which then uses the API to retrieve additional documented data or reconcile the completed snapshot. Another system may simply poll on its own schedule. The right choice depends on your workflow, latency needs, retry handling, and security model.
Whichever pattern you choose, protect API keys server-side, keep webhook secrets private, and test with synthetic data. DropRFID is extensible through documented APIs and signed webhooks, while the exact WMS, ERP, BI, or customer-connected AI behavior remains configuration-dependent.
Start with the developer documentation and a 14-day free trial at DropRFID.com.
The operational detail is in the edges: timeouts, retries, signatures, and replay handling. A pull-based service should record the last successful cursor or timestamp it used, while a webhook receiver should acknowledge safely and queue downstream work. Neither pattern removes the need to reconcile data. Build a small test matrix around a completed session, a duplicate notification, an unavailable destination, and an invalid secret. That makes the integration behavior visible before real operational traffic depends on it. Document the chosen pattern next to the service owner and escalation path, so a future maintainer knows whether to inspect polling, delivery logs, or both.
Keep the receiver and poller test data clearly synthetic during development.
