Officially, events are delivered as they occur, and in “near real-time.” That means two things. First, events are not queued up and sent in batches. When a new user account is created, an entityCreated event is generated. If there’s a webhooks subscription listening for entityCreated events then a webhooks notification is sent. If another account is created a second or two later, a second webhooks notification is sent. If 1,000 more accounts are created in the next hour or so then 1,000 more webhooks notifications will be sent. That’s the nature of webhooks: each event triggers its own notification.
Important. We should emphasize that accounts created by calling the entity.bulkData endpoint do not generate webhook events: if you use the entity.bulkData endpoint to create 10,000 user accounts you won't get any webhook notifications. That's because entity.bulkData doesn't generate entityCreated events; as a result, there's nothing for Webhooks v3 to report. This is also true if you use the dataload data migration script: because the dataload script relies on the entity.bulkCreate endpoint that means that no webhook events are generated during a data migration.
Let’s say an event of interest just occurred; how long will it take before Webhooks v3 sends a notification of that event? To be honest, the answer to that can be a bit complicated. Under the covers, things aren’t always as easy as:
- An event occurs.
- A webhook notification is sent and received.
What kinds of things can complicate the process? For one, the network might be congested at the Akamai end: that means it could take longer for events to get pushed out to the customer. Alternatively, things might be congested at your end. For example, suppose your listener endpoint can only handle 10 notifications per minute (which, admittedly, is an unrealistically-low value). Let’s further suppose that 100 people just registered on your website. That means that 100 event notifications are on their way to an endpoint that can only handle 10 such notifications per minute. In a case like that, delays are inevitable.
We should also note that Akamai can’t guarantee that notifications will be delivered in the exact order in which those events occurred. Suppose events 1, 2, 3, 4, and 5 occur in rapid-fire succession. Typically you’ll receive your event notifications in that exact same order: 1, 2, 3, 4, and 5. However, it’s possible that you might receive the notifications in this order: 1, 2, 3, 5, 4. That’s just the way the system works.
To help keep the system moving as efficiently, and as quickly, as possible, the Identity Cloud constantly monitors for such things as:
- The number of events currently in the event pipeline.
- The number of outgoing notifications.
- The success and failure rates for webhook deliveries.
- The distribution rate for delivery times.