Limitations
System constraints. Message size, request rate, endpoint quotas, feed retention, payload link validity, and confirmation batches
agrirouter enforces several system constraints you need to know about when developing and operating an integration.
Message Size
The maximum payload size accepted by the API is 256 MB per request. Payloads larger than that are rejected with HTTP 413.
Request Rate
Requests to the current API are rate limited per application, across all of its endpoints and tenants. The current default is 40 requests per second sustained, with a burst of 80. When the limit is exceeded, the gateway responds with HTTP 429 and no Retry-After header, so the client owns the backoff schedule.
The limiter runs locally on each gateway instance behind the load balancer. Connections that land on different instances are counted separately, so the effective allowance for a client that spreads requests over many connections is somewhat higher than the default. Do not design for more than the default.
Rate limits on the Errors page: response shape and backoff guidance7 minEndpoints per Account
Endpoints created through the current API (PUT /endpoints/{externalId}) are not subject to a fixed quota today. The legacy onboarding flow limits an account to 300 endpoints. Contact agrirouter support if you plan to register an unusually large number of endpoints per account, for example thousands of virtual communication units.
Feed Storage
Messages stay in an endpoint's feed until the receiving application confirms them, for at most 28 days after arrival:
- After 21 days without confirmation, the account owner is notified by email that messages are about to expire.
- After 28 days, unconfirmed messages are deleted and the account owner is notified again. The data is no longer available to the receiving application.
An integration that can be offline for longer than the retention period loses data. Confirm messages as soon as they are processed.
Payload Links
payload_uri links on MESSAGE_RECEIVED and FILE_RECEIVED events are pre-signed and valid for 15 minutes. After that, reconnecting to GET /events replays the unconfirmed event with a fresh link.
Confirmations per Request
POST /confirmations has no fixed maximum batch size. Each confirmation is processed individually, but the whole request is rejected with 403 if any of the endpoint IDs does not belong to your application, and a 5xx in the middle of a batch leaves the earlier confirmations applied. Keep batches at a few hundred entries so partial results stay easy to reason about.
The operation is idempotent, so trying to confirm messages that have been confirmed already does not break the process.