Implementation Review

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.
• For the review session, two distinct test accounts on your platform that can both be onboarded to agrirouter, plus an IO-Tool endpoint onboarded in one of the test agrirouter accounts to act as the counterpart for message exchange tests.

What the review covers

The review walks through your integration end-to-end and runs the explicit checks below. Sections marked VCU only apply to integrations that register virtual_communication_unit endpoints; skip them otherwise. Each item is phrased so it can be verified independently — the reviewer goes through them one by one and records any deviation.

Onboarding

Path 1: Initiated from your application

The user starts on your platform and is sent to agrirouter to grant consent.

• The user is redirected from your application to the agrirouter authorization screen.
• If the user rejects: they return to your application, and your UI shows a visible error message explaining the rejection.
• If the user accepts: they return to your application, and a new endpoint is visible in agrirouter. Run the Endpoint configuration checks below against that endpoint.

After the happy-path test, leave the endpoint in place for later checks.

Path 2: Initiated from agrirouter (Deep URL)

The user discovers your application from inside agrirouter and starts the connection there. To exercise this path without a published Solution Finder entry, manually open the Deep URL in the browser.

• Your application presents the user with a confirmation screen asking whether to onboard to agrirouter.
• After confirmation, the flow proceeds exactly as Path 1 from the redirect to the authorization screen onward, and the same Endpoint configuration checks apply.

Endpoint configuration checks

Run these against every endpoint your application creates (cloud_software and, where applicable, each virtual_communication_unit):

• Capabilities match the message types and directions your application actually sends and receives.
• Subscriptions are declared, or a documented reason is given for declaring none.
• Name identifies the source account in a way an end user will recognize — for example, email address, organization name, or person name.
• External ID follows the recommended format and is unique across the application.
• Type is set correctly (cloud_software or virtual_communication_unit).
• allow_delete_by_user is set to the value your platform expects (see Offboarding for the implications).
• The agrirouter control center shows the correct application name, brand, and logo for the connected endpoint.

Account-combination matrix

The reviewer exercises these combinations to confirm that one account on your platform can map to multiple agrirouter accounts and vice versa:

Each onboarding in the matrix must independently pass the endpoint configuration checks above.

Managing Virtual Communication Units (VCU only)

If your application registers a virtual_communication_unit per machine, additionally verify:

• A VCU endpoint exists for every eligible machine exposed by your platform.
• Each VCU passes the Endpoint configuration checks on its own.
• Renaming a machine on your platform is reflected as a name change on the corresponding VCU in agrirouter.

If your platform supports per-machine exposure controls, also verify:

• Removing one machine from agrirouter exposure on your platform causes its VCU to disappear in agrirouter.
• Re-adding the same machine causes its VCU to re-appear.
• When allow_delete_by_user == true for the VCU, deleting the VCU in agrirouter is reflected in your platform's machine state. allow_delete_by_user should not be set to true if your platform does not support per-machine management.

Message sending

These checks require two distinct agrirouter accounts connected by your application, with an IO-Tool endpoint onboarded in one of them to act as the receiving counterpart.

For every endpoint type in your application that declares a send capability, the reviewer runs the full set of checks below. If both a cloud_software and a virtual_communication_unit endpoint can send, both are exercised end-to-end.

• The user can either pick one or more target endpoints from your UI (preferred for interactive flows) or your application publishes the message automatically (preferred for background flows).
• The sending endpoint on the outbound request is set correctly. When a message is sent on behalf of a VCU, the request carries that VCU's endpoint ID, not the parent cloud_software endpoint's.
• The file arrives at the target endpoint, verified by reading the IO-Tool inbox.
• The HTTP headers on the outbound message are valid.
• A filename is provided, even though the header is technically optional.

Edge case: connector outage

The reviewer simulates an outage of the connection between your application and agrirouter using one of:

1. Configuring your connector to point at invalid agrirouter API endpoints.
2. Disabling the connector on your platform.
3. Temporarily revoking the OAuth credentials used by the connector.

With the connector disconnected:

• Triggering a send from your application produces either a user-visible error (interactive flows) or the message is queued for later delivery (background flows; queueing is also acceptable for interactive flows).

After reconnecting the connector:

• Queued or retried messages are delivered correctly, and the IO-Tool inbox receives them.

Message receiving

These checks also require two distinct agrirouter accounts connected by your application and an IO-Tool endpoint onboarded in one of them to act as the sender.

The reviewer runs a payload-type × target matrix from IO-Tool. Delivery mode (directly addressed vs. published) is irrelevant on the receiving side — the same event arrives either way — so it is exercised on the sending side only. Chunked payloads surface as FILE_RECEIVED SSE events after reassembly; non-chunked payloads surface as MESSAGE_RECEIVED events.

For every row in the matrix, verify:

• The payload is received in the correct account on your platform and surfaces in the correct context for the addressed endpoint.
• For VCU targets, the payload is forwarded to the machine without further user interaction wherever possible.
• After processing, receipt is confirmed so the feed count for that endpoint returns to 0 in the agrirouter control center's Endpoint Details view.

Edge case: connector outage

Using the same disconnection methods as for sending, with the connector disconnected:

• IO-Tool addresses messages to any endpoint of your application; the feed count for those endpoints grows and stays non-zero — your application does not confirm what it has not processed.

After reconnecting the connector:

• The queued messages are processed and confirmed, and the feed count returns to 0.

Offboarding

The reviewer exercises every offboarding path your application supports:

• Delete from agrirouter (only when allow_delete_by_user == true): the user deletes the endpoint inside agrirouter; your platform reflects the disconnected state for the corresponding account or machine.
• Disconnect from your platform: when the user removes the agrirouter connection on your platform, all of that user's endpoints in agrirouter are deleted.
• Revoke from agrirouter: when the user revokes the authorization to your application in agrirouter, your platform reflects the disconnected state.
• Re-onboarding after offboarding succeeds — the same user can connect again and a fresh endpoint is created with the expected configuration.

Cross-cutting requirements

These apply to every endpoint type, regardless of which sections above are in scope:

• Application message IDs (x-agrirouter-context-id) must be a UUID generated fresh for every payload. Reuse the same UUID only when retrying the exact same payload after a failure — never across distinct payloads.
• Buffering: when the connection to agrirouter is lost, the application buffers outbound messages and sends them once the connection is restored.
• Error handling: the application reacts correctly to HTTP error responses and to network errors, with retry logic for transient failures.

How to request a review

Once your integration is feature-complete and you have a good feeling you will pass the 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.
• provide a fully functional account to your platform so the agrirouter team can make their own testing before and after the live-session.
  • if you agree, this account may also be used to showcase the integration to other partners or in agrirouter materials.

How the review session runs

The review is a live session led by your developer. You drive each scenario from the checks above; the agrirouter team observes, asks follow-up questions, and records the outcome of every item.

The team 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:

When a re-review is required, create a new application version if your capabilities change, declare the changes, and submit the new version through the same review flow. Then, write to support@agrirouter.com with your request for re-review.

Next steps