Implementation Review
How the agrirouter team reviews your application before it can connect to production. What we look for, prerequisites, and the status flow.
Before your application can communicate with production agrirouter, the agrirouter team runs through an implementation review with you. The review confirms your integration implements the API correctly and behaves reliably for end users. It replaces the older external certification process.
When a review is required
A review is required when:
- You are connecting a new application to agrirouter for the first time.
- You make changes to an existing application that affect how it communicates with agrirouter (see Re-review below).
Prerequisites
Before requesting a review, make sure you have:
- A signed provider agreement with the agrirouter operator.
- Your company information and support contact details registered.
- A developer account with an approved application and at least one application version. See Setup Application for the steps to get there.
What the review looks at
The review covers the parts of your integration that affect protocol correctness, data quality, and end-user experience. Exact scope depends on your endpoint type and declared capabilities, but the areas below are always in scope.
- Authorization flow (OAuth 2.0 redirect, consent handling, error paths)
- Endpoint creation and deletion via the gateway API
- Capability declaration that matches what the application actually sends and receives
- Message sending and receiving for all declared capabilities
- Event handling via the SSE stream
- Error handling for both transport and validation errors
- Authorization flow on behalf of the underlying account
- Per-VCU endpoint creation, with one endpoint registered per machine
- Per-VCU capability declarations
- EFDI Device Description sending
- Telemetry payloads (EFDI Time Log, GPS) sending
- Receiving and acknowledging task data
Cross-cutting requirements
These apply to every endpoint type:
- Timestamps must be in UTC and use ISO 8601 format.
- Application message IDs (
x-agrirouter-context-id) must be unique per payload and at most 50 characters. UUIDs are recommended but not required; any string that is unique per payload is accepted. - Buffering: when the connection to agrirouter is lost, the application buffers outbound messages and sends them once the connection is restored.
- Billing hygiene: the application must not generate unnecessary message traffic that inflates billing for end users.
- Chunking: payloads larger than the internal chunk size are handled correctly on both the send side (
content-lengthandx-agrirouter-context-idset on every send) and the receive side (oneFILE_RECEIVEDevent per reassembled payload, with every ID inmessage_idsconfirmed after processing). - Error handling: the application reacts correctly to HTTP error responses and to network errors, with retry logic for transient failures.
Status flow
Your application moves through these statuses during and after the review:
| Status | Description |
|---|---|
| New | Application registered, no review requested yet. |
| Submitted | You have asked for a review. The agrirouter team has the request in its queue. |
| Approved for Testing | The agrirouter team has started reviewing your application. |
| Approved | The review passed. Your application can connect to production agrirouter. |
| Rejected | The review surfaced issues. Address them and resubmit. |
| Blocked | The application was previously approved but has been blocked, typically due to compliance issues. |
How to request a review
Once your integration is feature-complete and you have exercised the cross-cutting requirements above, write to support@agrirouter.com with:
- The application ID and application version ID of the version you want reviewed.
- A short summary of what the application does and which capabilities it uses.
- Sample messages that the application sends and receives, where useful.
The team reviews the submission, walks through the areas above with you, and updates the application status when the review concludes.
Re-review
A re-review is required when an existing application changes in ways that affect how it communicates with agrirouter:
| Change | Re-review required? |
|---|---|
| Adding new message types or directions | Yes |
| Changing communication patterns in a way that affects protocol behaviour | Yes |
| Adding or removing API operations the application uses | Yes |
| Bug fixes that do not change protocol behaviour | No |
| UI changes with no protocol impact | No |
When a re-review is required, create a new application version, declare the changes, and submit the new version through the same review flow.