UrbanPiper · Rate Limits

Urbanpiper Rate Limits

UrbanPiper's POS-integration API does not publish numeric account-wide rate limits in its public documentation. It does document payload-size constraints rather than per-minute request quotas: the Add/Update Items (Hub) action is limited to 400 items/options per request, and bulk catalogue/store payloads are required for menu, store and toggle operations. Asynchronous processing and a webhook circuit breaker / retry mechanism govern callback delivery. Specific per-endpoint request limits are not reconciled in this artifact.

Urbanpiper Rate Limits is the machine-readable rate-limit profile for UrbanPiper on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring items, records, and requests.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Restaurants, Food Delivery, Ordering, POS, and Aggregators.

3 Limits Throttle: 429
RestaurantsFood DeliveryOrderingPOSAggregatorsCommerceRate LimitingQuotasThrottling

Limits

Items/Options Per Request (Hub Items) request
items
400
The Add/Update Items (Hub) action is limited to 400 items/options per request.
Bulk Payload Requirement request
records
bulk required
Add/Update Stores, Add/Update Menu and Menu Toggle requests must be sent as bulk payloads; individual per-record requests are not accepted.
Request Rate (RPM) account
requests
see provider documentation
No numeric per-minute request rate is published; confirm with POS support.

Policies

Asynchronous Processing
Item/option action and catalogue requests are processed asynchronously; results are returned via callbacks rather than synchronously.
Webhook Circuit Breaker
A circuit breaker governs outbound webhook delivery; failed order webhooks can be retried via the webhook retry endpoint.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor any Retry-After guidance.

Sources