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.
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
Short answers written so search and answer engines can cite them.
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 configure-webhook-feedback-loop tutorial and the webhook retries blog. Signatures and retries matter more than the URL path.