Time Slot Capacity Changed | NaviPartner

Event timeslot_capacity_changed. Reports a time slot running low on tickets, and again when capacity is released.

The event tells you that a slot’s capacity changed, not what changed it. The payload carries no order or reservation reference, and the envelope’s initiatingUserAADObjectId identifies the session that raised the event rather than the person who submitted it. That field is empty unless the session has a Microsoft Entra identity. Your own sales raise events like any other, and you cannot filter them out.

Subscription works as it does for every other webhook, and covers a single company. See the Webhook Integration Guide.

When it fires

Three conditions must hold before any event is raised for a slot:

Capacity control is sales. The other controls count admissions or seats rather than sales.
The slot has a capacity ceiling.
Notify At Remaining Qty. is set. It starts at zero, which leaves the event disabled. It can be set on the admission, the admission schedule or the schedule line, and Capacity Limits By decides which one applies.

That quantity is the low-capacity threshold. A change to a qualifying slot fires the event when remaining capacity lands at or below the threshold, and again when a change lifts the slot back above it.

One event per slot per transaction, raised once it commits. A transaction touching several slots produces one event for each. No event is raised when:

the transaction rolls back
the slot stays above the threshold throughout
the slot’s net change is zero, as in a delete-and-reissue or a reversal pair

The threshold also governs volume. Below it, expect roughly one event per sale, plus the release events. A basket of four tickets is one event, not four. Setting the threshold to the slot’s full capacity requests an event for every sale: reasonable on a small slot, heavy on a large one.

Reading the numbers

maxCapacity and remainingCapacity are the admission’s own figures for the slot. A ticket product can be capped at a percentage of the admission’s capacity, and Search Time Slots reports the figures scaled to that cap under the same two field names.

remainingCapacity is the slot’s remaining capacity at the moment it was read, counted without locking.

It can include sales still in flight that may never complete.
It can be stale on arrival: the count is taken when the change occurs, but dispatch waits for the transaction to commit.
Judge it against the quantity you are about to sell: a wide margin is reliable, a narrow one may already have been taken by another session.

Do not gate a sale on it. Capacity is enforced at issuance: attempt the issuance and handle a rejection.

The capacityAsOf timestamp

capacityAsOf records when the count was read, in UTC.

The envelope’s timestamp is taken a moment later, when the event is raised; the difference between the two means nothing.
Where two events for one slot differ, the later value is the fresher count.
Where they match, neither is fresher: timestamps resolve to about three milliseconds and server clocks vary, so concurrent sales can read within one tick. Keep whichever arrived last.

Delivery

One request can carry several events. Entries in one delivery may be minutes apart, so do not assume a request holds a single event or a single slot.
Events arrive in no guaranteed order.
No redelivery is documented, so do not rely on one.

Deduplicate regardless: your own load balancer or queue can repeat an event the platform sent once.

Return 202 on receipt and do the work afterwards.

Event `timeslot_capacity_changed`. Reports a time slot running low on tickets, and again when capacity is released. The event tells you that a slot's capacity changed, not what changed it. The payload carries no order or reservation reference, and the envelope's `initiatingUserAADObjectId` identifies the session that raised the event rather than the person who submitted it. That field is empty unless the session has a Microsoft Entra identity. Your own sales raise events like any other, and you cannot filter them out. Subscription works as it does for every other webhook, and covers a single company. See the [Webhook Integration Guide](/apis/webhooks). ## When it fires Three conditions must hold before any event is raised for a slot: - Capacity control is `sales`. The other controls count admissions or seats rather than sales. - The slot has a capacity ceiling. - **Notify At Remaining Qty.** is set. It starts at zero, which leaves the event disabled. It can be set on the admission, the admission schedule or the schedule line, and **Capacity Limits By** decides which one applies. That quantity is the low-capacity threshold. A change to a qualifying slot fires the event when remaining capacity lands at or below the threshold, and again when a change lifts the slot back above it. One event per slot per transaction, raised once it commits. A transaction touching several slots produces one event for each. No event is raised when: - the transaction rolls back - the slot stays above the threshold throughout - the slot's net change is zero, as in a delete-and-reissue or a reversal pair **The threshold also governs volume.** Below it, expect roughly one event per sale, plus the release events. A basket of four tickets is one event, not four. Setting the threshold to the slot's full capacity requests an event for every sale: reasonable on a small slot, heavy on a large one. ## Reading the numbers `maxCapacity` and `remainingCapacity` are the admission's own figures for the slot. A ticket product can be capped at a percentage of the admission's capacity, and [Search Time Slots](/apis/api-reference/ticketing/service-capacity/search-time-slots) reports the figures scaled to that cap under the same two field names. `remainingCapacity` is the slot's remaining capacity at the moment it was read, counted without locking. - It can include sales still in flight that may never complete. - It can be stale on arrival: the count is taken when the change occurs, but dispatch waits for the transaction to commit. - Judge it against the quantity you are about to sell: a wide margin is reliable, a narrow one may already have been taken by another session. Do not gate a sale on it. Capacity is enforced at issuance: attempt the issuance and handle a rejection. ## The capacityAsOf timestamp `capacityAsOf` records when the count was read, in UTC. - The envelope's `timestamp` is taken a moment later, when the event is raised; the difference between the two means nothing. - Where two events for one slot differ, the later value is the fresher count. - Where they match, neither is fresher: timestamps resolve to about three milliseconds and server clocks vary, so concurrent sales can read within one tick. Keep whichever arrived last. ## Delivery - One request can carry several events. Entries in one delivery may be minutes apart, so do not assume a request holds a single event or a single slot. - Events arrive in no guaranteed order. - No redelivery is documented, so do not rely on one. Deduplicate regardless: your own load balancer or queue can repeat an event the platform sent once. Return `202` on receipt and do the work afterwards.

Payload

The payload of this webhook request is an object.

valuelist of objectsRequired

An array of webhooks, be prepared to handle more than 1 in the same hook request.

Response

200

any

Return a 200 status to indicate that the data was received successfully.

When it fires

Three conditions must hold before any event is raised for a slot:

Capacity control is sales. The other controls count admissions or seats rather than sales.

The slot has a capacity ceiling.

Notify At Remaining Qty. is set. It starts at zero, which leaves the event disabled. It can be set on the admission, the admission schedule or the schedule line, and Capacity Limits By decides which one applies.

One event per slot per transaction, raised once it commits. A transaction touching several slots produces one event for each. No event is raised when:

the transaction rolls back

the slot stays above the threshold throughout

the slot’s net change is zero, as in a delete-and-reissue or a reversal pair

Reading the numbers

remainingCapacity is the slot’s remaining capacity at the moment it was read, counted without locking.

It can include sales still in flight that may never complete.

It can be stale on arrival: the count is taken when the change occurs, but dispatch waits for the transaction to commit.

Judge it against the quantity you are about to sell: a wide margin is reliable, a narrow one may already have been taken by another session.

Do not gate a sale on it. Capacity is enforced at issuance: attempt the issuance and handle a rejection.

The capacityAsOf timestamp

capacityAsOf records when the count was read, in UTC.

The envelope’s timestamp is taken a moment later, when the event is raised; the difference between the two means nothing.

Where two events for one slot differ, the later value is the fresher count.

Where they match, neither is fresher: timestamps resolve to about three milliseconds and server clocks vary, so concurrent sales can read within one tick. Keep whichever arrived last.

Delivery

One request can carry several events. Entries in one delivery may be minutes apart, so do not assume a request holds a single event or a single slot.

Events arrive in no guaranteed order.

No redelivery is documented, so do not rely on one.

Deduplicate regardless: your own load balancer or queue can repeat an event the platform sent once.

Return 202 on receipt and do the work afterwards.