Ecosystem

The agrirouter ecosystem covers everyone involved in agricultural data exchange: the farmers and contractors who own and operate machines, the software companies that build tools for them, and the machines themselves. agrirouter sits in the middle as a neutral data exchange hub, so these participants can communicate without each building a direct integration to every other one.

Loading diagram...

One Application Type, Three Endpoint Types

agrirouter has a single application type: every new application that integrates with it (a farm management app, a fleet management backend, an advisory tool) registers as the same kind of application. The axis of variation that actually matters for integration work is the endpoint type. An application creates one or more endpoints in an end user's account, and each endpoint declares which type it is when it is created via PUT /endpoints/{externalId}.

The API distinguishes endpoint types you can create through the current API from types you may only observe on existing endpoints created via the legacy API.

Types you can create with PUT /endpoints/{externalId}:

Types you may also observe on endpoints in a tenant, but cannot create through the current API:

The rest of this page covers each creatable type in turn, then the concepts that are common to all endpoints: how they are identified, how data flows between them, and who controls that flow.

cloud_software

cloud_software endpoints are cloud-hosted applications (web and mobile applications, backend services, fleet management platforms, advisory tools) that connect to agrirouter over HTTPS to exchange data on behalf of their users. They authenticate using client credentials, so the integration is only viable in environments that can securely store a secret. Untrusted clients like browser-only or desktop applications are not a supported deployment model.

A single installation or tenant of a cloud software product usually maps to one endpoint per end-user account: two different end users each have their own agrirouter account with their own cloud_software endpoint, isolated from each other. The same end user can also have several cloud_software endpoints in a single account when the connected software wants to represent organisational units separately, for example distinct farms, subsidiaries, or user accounts inside the application.

Telemetry platforms, the cloud systems that historically acted as the "concentrator" for a fleet of machines, are just cloud_software endpoints in the current API. A telemetry platform only needs its own endpoint if the platform itself participates in data exchange as a distinct party (for instance, to receive aggregated fleet data). It is no longer the connection point for the machines it manages: each machine is registered directly as its own virtual_communication_unit endpoint.

virtual_communication_unit

A virtual_communication_unit (VCU) endpoint represents a physical machine (a tractor, implement, or ISOBUS-connected unit) taking part in agricultural data exchange. A VCU is a full-fledged endpoint with its own external ID, capabilities, and subscriptions, registered via its own PUT /endpoints/{externalId} call, just like any other endpoint. It receives its own events and is addressable as a distinct source and destination when the end user configures routes in their account.

Messages sent by a VCU can carry a TeamSet context ID that identifies which group of connected machines the message belongs to. A TeamSet is a set of machines that work and move together and are connected to the same (virtual) communication unit, typically linked physically and informationally over ISOBUS. See TeamSet Context ID for the wire-level contract.

See the Virtual Communication Units guide for integration details, including how to register a VCU and report its TeamSets.4 min

farming_software (deprecated)

Legacy Communication Units

Physical hardware devices (terminals, telemetry boxes, or ISOBUS gateways installed on machines) historically connected to agrirouter as Communication Units (CUs) via the legacy API. CUs are not an endpoint type in the current API: there is no way to create a CU through it. Hardware manufacturers building a physical device should follow the separate Communication Unit integration guide for the legacy surface.

Coming from older docs or an existing integration? See Migrating from Legacy for a term-by-term mapping, including the difference between CU and VCU.3 min

Machine Identification

When a VCU participates in data exchange, the platform needs to know which physical machines are present and what they can do. That is captured in EFDI Device Descriptions, also known as TeamSets: a structured message sent by the VCU that reports the connected devices, their properties, and how they are grouped.

TeamSets are tied together across messages by a TeamSet context ID that the VCU carries on every related send, so receivers can line up telemetry, task data, and device descriptions that belong to the same on-machine setup.

See EFDI Device Descriptions for the wire-level message contract. See TeamSet Context ID for the header name, when to set it, and when to generate a new value.

Data Flow Control

The core principle of agrirouter is that the end user controls all data flow. No data moves between endpoints automatically. The account owner must explicitly configure a route in the agrirouter UI.

A route specifies:

• A source endpoint that sends data
• A destination endpoint that receives data
• The message types that are allowed to flow along the route

This keeps farmers and contractors in full control of their agricultural data. They decide exactly which software and machines can exchange which types of information.

Alongside individually configured routes, the end user can enable managed routes for an endpoint. Managed routes automatically connect a machinery endpoint (a virtual_communication_unit) with every software endpoint (a cloud_software or legacy farming_software) in the account for their shared message types, and vice versa. They only bridge the machinery ↔ software divide: two VCUs are never connected to each other by a managed route, and neither are two software endpoints.

Learn more about routes, subscriptions, and message flow in the Messaging section.9 min

Member Roles

The agrirouter ecosystem has two primary roles.

End Users

End users are the farmers and contractors who own agrirouter accounts. They are the data owners. An end user:

• Creates and manages an agrirouter account
• Connects their software and hardware to the account (creating endpoints)
• Controls data flow by configuring routes between endpoints
• Can share data with other end users (for example, a farmer sharing field data with a contractor)

The end user is always in control. No data moves between endpoints unless the account owner has configured a route for it.

App Providers

App providers are the companies that build integrations with agrirouter. An app provider:

• Registers as a developer on the agrirouter platform
• Creates one or more applications (software products) that integrate with agrirouter
• Submits applications for implementation review before they can be used in production
• Manages the technical aspects of the integration (authorization, endpoint creation, messaging)

A single app provider company may offer several applications, for example a farm management software product and a separate fleet management backend.