Docs

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

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-length and x-agrirouter-context-id set on every send) and the receive side (one FILE_RECEIVED event per reassembled payload, with every ID in message_ids confirmed 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:

StatusDescription
NewApplication registered, no review requested yet.
SubmittedYou have asked for a review. The agrirouter team has the request in its queue.
Approved for TestingThe agrirouter team has started reviewing your application.
ApprovedThe review passed. Your application can connect to production agrirouter.
RejectedThe review surfaced issues. Address them and resubmit.
BlockedThe 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:

ChangeRe-review required?
Adding new message types or directionsYes
Changing communication patterns in a way that affects protocol behaviourYes
Adding or removing API operations the application usesYes
Bug fixes that do not change protocol behaviourNo
UI changes with no protocol impactNo

When a re-review is required, create a new application version, declare the changes, and submit the new version through the same review flow.

Next steps

On this page