Skip to content
IT Canvass
APIs & integration · Lesson

Webhooks

Quick answer

Webhooks (event triggers) let SailPoint push notifications to your endpoint when events occur, so you react to changes instead of polling.

Key takeaways

  • Push notifications on events
  • React instead of polling
  • Verify signatures for security
  • Respond quickly, process async

Webhooks, delivered in SailPoint via event triggers, let the platform push a notification to your endpoint the moment something happens (an identity is created, access is requested, a certification completes). This event-driven model is far more efficient than repeatedly polling the API to ask “has anything changed yet?”.

How event triggers work

You register an HTTPS endpoint to receive specific event types. When such an event occurs, SailPoint sends a signed JSON payload to your endpoint. Your service verifies the payload, acknowledges quickly, and processes the event, reacting in near-real-time instead of on a polling schedule.

Building a reliable receiver

  • Verify the signature so you only act on genuine SailPoint events.
  • Return 200 fast, then process asynchronously; do not do heavy work inline and risk a timeout.
  • Be idempotent, the same event may be delivered more than once, so processing it twice must be safe.
  • Handle retries, if you fail to acknowledge, delivery may be retried.

Webhooks versus polling

Polling wastes calls (most return “no change”) and adds latency (you only learn of changes at the next poll). Webhooks invert this: near-instant, no wasted calls. Where an event trigger exists for what you need, prefer it; fall back to polling only when no suitable event is available.

Common pitfalls

  • No signature verification, accepting spoofed events.
  • Heavy synchronous processing causing delivery timeouts.
  • Non-idempotent handlers double-processing duplicate deliveries.

Want to learn this properly?

Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.

Check your understanding

  1. What do webhooks do?

    • A. Return 200 quickly and process the event asynchronously.
    • B. Because events may be delivered more than once.
    • C. Push event notifications to your endpoint so you react instead of polling.
    Show answer

    C. Push event notifications to your endpoint so you react instead of polling.

    Push event notifications to your endpoint so you react instead of polling.

  2. How should handlers respond?

    • A. Return 200 quickly and process the event asynchronously.
    • B. Push event notifications to your endpoint so you react instead of polling.
    • C. Because events may be delivered more than once.
    Show answer

    A. Return 200 quickly and process the event asynchronously.

    Return 200 quickly and process the event asynchronously.

  3. Why make handlers idempotent?

    • A. Push event notifications to your endpoint so you react instead of polling.
    • B. Because events may be delivered more than once.
    • C. Return 200 quickly and process the event asynchronously.
    Show answer

    B. Because events may be delivered more than once.

    Because events may be delivered more than once.

Frequently asked questions

What does the term Webhooks refer to in SailPoint?

Webhooks, delivered in SailPoint via event triggers, let the platform push a notification to your endpoint the moment something happens (an identity is created, access is requested, a certification completes).

What is worth remembering about Webhooks in practice?

When such an event occurs, SailPoint sends a signed JSON payload to your endpoint.

What is another point to note about Webhooks?

Your service verifies the payload, acknowledges quickly, and processes the event, reacting in near-real-time instead of on a polling schedule.

What tends to go wrong with Webhooks?

No signature verification, accepting spoofed events. Heavy synchronous processing causing delivery timeouts. Non-idempotent handlers double-processing duplicate deliveries.
CallWhatsAppEnquire