Paytronix · Rate Limits

Paytronix Rate Limits

Paytronix does not publish numeric request-rate, concurrency, or quota limits in its public integration documentation (the API Primer and PXS API Reference describe authentication, formatting, versioning, and service-level error codes, but no rate-limit numbers or rate-limit headers). Access is provisioned per integration via an integration identifier and secret, so any applied throttling is governed by the integration agreement rather than a public tier. The limits below are therefore descriptive placeholders with string values pointing at the documentation; reconciled is false because no numeric limits could be verified. Confirm specific limits with Paytronix during integration onboarding.

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

It captures 2 rate-limit definitions, measuring varies.

The profile also includes 3 backoff/retry policies defined and response codes documented for badRequest, unauthorized, forbidden, and notFound.

Tagged areas include Rate Limiting, Loyalty, and Online Ordering.

2 Limits
Rate LimitingLoyaltyOnline Ordering

Limits

Server (PXS) API requests integration
varies
not publicly documented — governed by the integration agreement
No per-second or per-minute numbers are published; the PXS API Reference documents service-specific error codes but not throttling thresholds.
Online Ordering API requests integration
varies
not publicly documented — see docs.opendining.net
The Open Dining documentation does not publish request-rate or concurrency limits for the ordering endpoints.

Policies

Per-integration scoping
Requests are authenticated with a per-integration identifier and secret (HTTP Basic); any applied limits are scoped to the integration and negotiated during onboarding rather than published as public tiers.
Confirm during onboarding
Because no public numeric limits exist, integrators should confirm acceptable request rates, batch sizes, and concurrency with Paytronix before launch, especially for high-volume POS and batch operations.
Backoff and retry
No Retry-After header is documented; clients should implement conservative exponential backoff on 4xx/5xx responses and idempotent retries keyed on externalTransactionId where supported.

Sources