Webhooks vs polling
Polling repeatedly requests status. Webhooks deliver an event when a decision, screening result, or investigation outcome is ready. Fraud and AML programs that REVIEW asynchronously need the push path.
| Dimension | Webhooks | Polling | Where Naiza fits |
|---|---|---|---|
| When to use | Decision or screening follow-up as it happens | Reconciliation and missed-event recovery | Webhooks plus an events query for gaps |
| Failure mode | Unsigned or unretried deliveries | Gaps between poll windows | Signed callbacks and idempotent event processing |
When polling is enough
Synchronous evaluate-and-decide on a payment can return ALLOW/BLOCK in the HTTP response. You still persist the event id. Polling every second for that id is wasted load.
When webhooks win
Async events, overnight list re-screens, and analyst feedback. Naiza documents webhooks and a feedback API. Verify signatures, queue work, and send investigation labels back.
Reliability
Retry from your queue, not inside the HTTP handler. Make feedback idempotent with your case id. Tutorials cover the webhook feedback loop.
Frequently asked questions
Answers about screening, risk signals, and Naiza integration.
Should we poll the fraud API for every login?
No. Use the synchronous decision response. Polling is for rare status checks, not the hot path.
What belongs on a webhook?
Async REVIEW results, AML status changes, and events you accepted without blocking the user. Keep the event or screening id in the payload handling.
Where is Naiza’s webhook guide?
See the webhooks API reference and the webhook retries article. Signatures and retries matter more than the URL path.