Setup Application

Create a developer account

A developer account is built on top of a regular agrirouter end-user account. It includes everything an end-user account does, plus tools for managing applications, software versions, and developer-specific settings.

To get one:

1. Sign up for a regular end-user account on the agrirouter platform if you do not already have one.
2. Request that the account be promoted to a developer account from within your account's settings and then write to support@agrirouter.com. Promotion is reviewed and approved manually.

Two practical conventions:

• Use a generic company email address such as dev@yourcompany.com rather than a personal one. This keeps the account usable when team members change.
• Plan on one developer account per app provider. All developers in your organization share the same account.

Register your application profile

Once your developer account is active, open Developer > Applications and use Create application. The application profile is the stable product record that users and reviewers see. Complete these fields first:

• Application name, the name displayed to end users.
• Brand, the commercial product or company label shown with the application.
• Application type, the portal category for the application record. New current-API integrations should use Default application type. The other values are legacy compatibility types; see Application Types in the Developer Portal.
• Support URL, where users can get help with your integration.
• Deep URL, the HTTPS URL where users are sent when they start connecting from agrirouter. See Discovery via Deep URL.
• Logo, the visual identifier for your application in the agrirouter ecosystem.

The Developer Portal saves the application profile automatically. There is no separate save button: while required fields are still missing, the status indicator shows that autosave is pending. After the required fields are valid, autosave creates the application, assigns its Application ID, and opens the application workspace. For current application types, the required fields are application name, brand, application type, Support URL, and Deep URL.

The setup guide reads the saved application state. As soon as autosave creates the application and the required profile fields are saved, the guide moves on to the next unfinished setup item.

Support URL

The Support URL is the public help address for your application. agrirouter stores it on the application record and can show it to users when they need help from the application provider, for example when a connection cannot be managed or deleted directly from the agrirouter UI.

When registering a new application, the Developer Portal requires a valid URL here. Use a stable page that explains how users can contact your support team, find integration-specific help, or continue connection management in your own system.

After the application exists, the profile can still be maintained in the workspace:

• Edit the application name, logo, brand, support URL, and Deep URL directly from the profile and Technical details areas.
• Application metadata and software-version drafts autosave independently.
• Delete an application only while all of its versions are still drafts. Once a version enters the review lifecycle, keep the application and create a new version for later changes.
• Manage OAuth clients from Technical details. OAuth clients belong to the application as a whole, not to a single software version.

Work with software versions

A software version is the reviewable unit of an application. It records what a specific release does, which message types it sends or receives, and where it is in the review lifecycle.

Use Create version in Software versions to start a draft. The portal suggests the next version number from the existing versions. A version draft begins empty so the number can be reserved first, then the release description and capabilities can be filled in continuously.

The version row shows:

• Version number, the release number assigned in the portal.
• Lifecycle status, such as Draft, In review, Testing approved, or Approved.
• Latest, shown on the highest version number in the list.
• Actions, including the version ID and draft deletion while the version is still editable.

Expand the version row to edit the release description and capabilities. Draft changes autosave after each edit. Submit for review becomes available after the version has a saved release description and at least one saved capability.

Declare capabilities

Capabilities declare the message types the software version can send and receive. They should match the integration behavior that will be demonstrated during the implementation review.

Use Add capability to choose message types from the catalog. Capability rows are grouped by message-type family and can be toggled for send, receive, or both directions. Declare only what the version actually supports; the review uses this declaration as the scope for message exchange tests.

Use the Message Types reference before adding capabilities. It lists the supported technical message type identifiers, and the category pages explain payload formats, common use cases, and important constraints such as deprecated GPS messages or EFDI TeamSet context.

For details about what reviewers check against the declared capabilities, see Review Scope.

Submit an application version for approval

When the draft is complete and the autosave status is clear, click Submit for review on the version card. Submission locks that version for editing. The agrirouter team then moves the version through the review statuses:

The Application ID is shown in Technical details. The Version ID is available from the software version's actions menu. You will need both when creating an endpoint.

Obtain credentials

Your application authenticates against agrirouter using OAuth 2.0 client credentials, a client_id and client_secret. These credentials are tied to the application, not to a single software version, and they are used for every customer that authorizes your application. See Authorization and Security for the full flow.

Credentials are created self-service in the Developer Portal. Open your application, find Technical details, and use Auth clients to create one or more OAuth clients for the application.

Create an OAuth client

An application can have multiple OAuth clients. Use separate clients for environments such as production and QA, or for credential rotation where old and new deployments need to overlap briefly.

To create one, click Create in the Auth clients area, enter a recognizable name, and register the exact redirect URL your application will use during the authorization flow.

Store the one-time client secret

After the client is created, agrirouter shows the client_id and client_secret. The secret is shown only once. Copy it immediately into your secrets manager or deployment environment before closing the dialog.

Rotate or revoke OAuth clients

Existing OAuth clients are listed under Auth clients with their name and client_id. The client_secret is not shown again after creation. Use Rotate when a new secret is needed, then update your deployments before retiring the old value. Use Revoke client only after every environment using that client has been migrated.

Develop your integration

With your application registered and credentials in hand, you can start building the integration. Two notes on how we expect the integration to be built:

There are no official SDKs for the agrirouter API. Generate a client from the OpenAPI specification using a code generator for your language of choice, for example openapi-generator, NSwag, or Prism. The full specification is published on the API Reference, and you can render or browse it directly from there.

Use the IO-Tool as your test receiver and sender. The IO-Tool acts as a receiving and/or sending endpoint, so you can send and receive messages without running a second integrated application.

Request the implementation review

After the software version is submitted and the integration is ready to demonstrate, write to support@agrirouter.com and request the implementation review. For the full checklist, see Implementation Review.