Ecosystem
The agrirouter ecosystem: farmers, contractors, software, and machines
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.
Application Types in the Developer Portal
The Application type field in the Developer Portal describes the application record that belongs to an app provider. It is not the same thing as the endpoint type your integration creates later through the API.
For new current-API integrations, choose Default application type. That application record can create cloud_software endpoints, and it can also create virtual_communication_unit endpoints when the product represents physical machines on behalf of an end user.
The other application types are legacy compatibility values:
| Portal application type | Use it when |
|---|---|
| Default application type | You are building a current REST API integration. This is the default for new applications. |
| Telemetry Platform | You are maintaining an older application that was registered under the historical telemetry-platform model. New fleet integrations should use the default application type and create one virtual_communication_unit endpoint per machine. |
| Farming Software | You are maintaining an older farming-software application. New software integrations should use the default application type and create cloud_software endpoints. |
| Communication Unit | You are maintaining or registering a physical hardware Communication Unit (CU) that uses the legacy API. The Developer Portal shows legacy auth fields for this type and does not require a Deep URL. |
The application type is selected when the application profile is created. After creation, the value is shown read-only in the workspace. Endpoint types are still chosen by your integration when it creates endpoints for an end user's tenant.
Endpoint Types
Endpoint types describe the participants inside an end user's agrirouter account. An application creates endpoints through PUT /endpoints/{externalId}, and each endpoint declares its endpoint_type.
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}:
| Type | Represents |
|---|---|
cloud_software | A cloud-hosted application acting on behalf of an end user. |
virtual_communication_unit | A single physical machine, implement, or machine group participating in ISOBUS data exchange. |
farming_software | Legacy alias for cloud_software. Deprecated, use cloud_software for new endpoints. |
Types you may also observe on endpoints in a tenant, but cannot create through the current API:
| Type | Represents |
|---|---|
communication_unit | A physical hardware Communication Unit registered through the legacy API. |
telemetry_platform | A legacy concentrator-style platform endpoint. New integrations register each machine directly as its own virtual_communication_unit endpoint instead. |
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 such as web applications, mobile backends, fleet management platforms, advisory tools, and farm management systems. They 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-only 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 organizational 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 not a separate endpoint type in the current API. A telemetry platform only needs its own cloud_software endpoint if the platform itself participates in data exchange as a distinct party, for example to receive aggregated fleet data. The machines it manages should be registered directly as virtual_communication_unit endpoints.
virtual_communication_unit
A virtual_communication_unit (VCU) endpoint represents a physical machine such as a tractor, implement, or ISOBUS-connected unit taking part in agricultural data exchange. A VCU is a full endpoint with its own external ID, capabilities, subscriptions, feed, and endpoint ID. 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 minfarming_software (deprecated)
farming_software is a legacy endpoint type kept for backward compatibility. New applications should register their endpoints as cloud_software instead. The two behave identically today, and farming_software may be removed in a future version of the API.
Legacy Communication Units
Physical hardware devices such as 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 minMachine 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.4 min See TeamSet Context ID for the header name, when to set it, and when to generate a new value.4 minData 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, usually a virtual_communication_unit, with every software endpoint, usually a cloud_software or legacy farming_software, in the account for their shared message types, and vice versa. They only bridge the machinery-to-software divide: two VCUs are never connected to each other by a managed route, and neither are two software endpoints.
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 that integrate with agrirouter.
- Submits software versions for implementation review before they can be used in production.
- Manages the technical aspects of the integration, including authorization, endpoint creation, and messaging.
A single app provider company may offer several applications, for example a farm management software product and a separate fleet management backend.