Sync Availability And Products

👍

Scopes required: Product_Get, ProductAvailability_Get, Webhook_Create (recommended: Resource_Get, ResourceCalendar_Get for event/resource-based venues)

Strategy

1. Catalog sync (slow-moving): pull GET /products periodically (e.g. hourly) and on Product webhook events. Store product IDs, names, pricing display info and product types.
2. Availability (fast-moving): query GET /product-availability?date=... at browse/checkout time. Never cache availability for longer than a few minutes.
3. Event-driven invalidation: subscribe to Product (Created/Updated/Deleted) and Booking webhooks to invalidate caches immediately.

Pull the catalog

curl "https://api.roller.app/products" -H "Authorization: Bearer $TOKEN"

Map ROLLER product types to your marketplace's catalog model — see product type mapping. Not every type is sellable by a vendor (e.g. wallets, cashless cards); focus on passes, sessions, packages and stock.

Check availability at browse time

curl "https://api.roller.app/product-availability?date=2026-07-01&productIds=123456,123457" \
  -H "Authorization: Bearer $TOKEN"

Availability reflects schedules, sale periods and cut-offs, capacity (fixed or resource-driven), and visibility settings. Treat the response as the source of truth for what you may sell on that date.

Keep it fresh with webhooks

curl -X POST https://api.roller.app/webhooks \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://marketplace.example.com/hooks/roller",
    "enabled": true,
    "webhooks": {
      "product": { "events": ["Created", "Updated", "Deleted"] },
      "booking": { "events": ["Created", "Cancelled"] }
    }
  }'

On Product events, refresh the product; on Booking events, invalidate availability for the affected dates.

Rate-limit aware polling

The REST API allows 600 requests/minute per IP. For multi-venue marketplaces:

• Use one token per venue; spread scheduled syncs across the hour.
• Batch availability queries with productIds rather than one call per product.
• Prefer webhooks over polling wherever possible.