Restaurant365 · Rate Limits

Restaurant365 Rate Limits

Restaurant365 does not publish numeric per-second or per-minute request rate limits for the R365 API or OData connector. The documented constraints are data-volume limits enforced on the OData connector's sales views: sales data (SalesEmployee, SalesDetail, SalesPayment) is limited to a 31-day date range per request, and several high-volume sales endpoints are deliberately throttled to prevent pulling excessive data in a single call. Access is provisioned per customer through R365 Support, so effective ceilings are account-scoped. The recommended pattern is to retrieve header records (Transaction or SalesEmployee) and then query details by ID, using the rowVersion property for incremental pulls.

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

It captures 3 rate-limit definitions, measuring varies.

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

Tagged areas include Rate Limiting, OData, Reporting, and Accounting.

3 Limits Throttle: 429
Rate LimitingODataReportingAccounting

Limits

OData sales views date range account/service
varies
31-day maximum date range per request on SalesEmployee, SalesDetail, and SalesPayment
Exceeding the range returns "The filter exceeds the date limit of 31 days, please limit your date range and try again." Historical pulls must be chunked across multiple requests.
OData high-volume sales throttling account/service
varies
documented throttling on high-volume sales endpoints; no published numeric rate
Sales endpoints are intentionally throttled to limit data pulled per call. SalesEmployee, SalesDetail, and SalesPayment also do not support $select or $count.
R365 API request rate account
varies
no published numeric rate limit; account-provisioned via R365 Support

Policies

Incremental extraction
Use the rowVersion property to pull only records changed since the last sync rather than re-pulling full data sets.
Header-then-detail pattern
Query header views (Transaction, SalesEmployee) for IDs first, then query detail views by those IDs to avoid hitting volume throttles.
Date-range chunking
Split historical sales pulls into consecutive 31-day windows to stay within the documented date-range limit.
Access provisioning
API and OData access is enabled per customer/vendor by R365 Support; effective limits are account-scoped rather than publicly published.

Sources