Product availability

Read remaining capacity while keeping checkout's full availability rules in view.

Read current stock

GET /{event_id}/products/index.json returns a product array with configured stock and computed current_stock. For a normal finite product, current stock subtracts sold tickets, reservations and pending order holds from configured capacity. Recurring-date and guaranteed-stock rules can change that calculation.

[{"id":"22222222-2222-4222-8222-222222222222","title":"General admission","stock":100,"current_stock":72,"pending":3,"visible":1,"waitinglist":1,"ProductsPool":[{"pool":"1","sales":28}]}]

Unlimited configured stock is -1. Its current computed sentinel is 8388607; do not display that as literal finite ticket capacity. The list retains pending, but removes the separate times_sold and reserved fields. Don't reconstruct those counts from missing fields.

Check shared pools

ProductsPool[].sales reports shared-pool usage. Event metadata keys products_pool_{pool_id} contain configured limits. Products can share a pool, so two individually available ticket types may compete for the same remaining capacity. The organizer catalog includes sold-out products and does not clamp every current_stock value to its pool limit.

Full organizer configuration is available through /{event_id}/events/get_event_data.json, but it includes sensitive internal settings. Read only the metadata you need on your server. Use the organizer's pool settings when configuring limits and verify metadata write rules for your event.

Consider sales rules

• available_from/available_till define sales windows using legacy server-local timestamps.

• visible controls visitor visibility.

• Package component quantities and shared pools can constrain a bundle.

• Recurring dates and guaranteed invitation stock have their own capacity rules.

• waitinglist and keep_soldout_in_shop affect visitor shop behavior after sellout.

Avoid stale promises

A read does not reserve stock. Capacity can change between reading and paying. Refresh before displaying availability, treat the result as advisory, and let Paydro validate the visitor's final checkout. There is no separate inventory-hold API in this reference.

See waiting lists for issuing invitations and embedding for completing registration and payment.