weclapp · Rate Limits

Weclapp Rate Limits

weclapp applies request throttling on its per-tenant REST API to protect the shared platform, but does not publish a single fixed public number (requests per minute) that is stable across tenants and editions. Practically, clients should page efficiently (use pageSize and the /count endpoint), request only the properties they need (properties / additionalProperties), filter server-side with the per-property operators, and back off on HTTP 429. Because the API is per-tenant, throughput is also bounded by the tenant's plan and the underlying instance rather than by a documented global ceiling.

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

It captures 2 rate-limit definitions, measuring requests and results.

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

Tagged areas include ERP, CRM, Cloud ERP, Rate Limiting, and Quotas.

2 Limits Throttle: 429
ERPCRMCloud ERPRate LimitingQuotas

Limits

REST API Requests tenant
requests
not published
weclapp throttles API requests per tenant; a fixed public per-minute number is not documented.
Page Size request
results
configurable via pageSize
List endpoints return pageSize results per page; use page to paginate and /count to size result sets.

Policies

Pagination
Use page and pageSize on list endpoints; call /{entity}/count to size a result set before paging.
Field Selection
Request only needed fields with properties, and computed/related fields with additionalProperties, to reduce payload and load.
Server-Side Filtering
Filter with per-property operators ({property}-eq, -ne, -gt, -lt, -like, -in, -null, -notnull) instead of client-side filtering.
Backoff Strategy
On HTTP 429, back off with exponential delay and jitter and honor any Retry-After header before retrying.

Sources