Fleetcore. Fleetcore. · Developer Portal
Produkt av ITDOK AS
Norsk Bokmal
Public developer portal

Integrate with FleetCore through a clear access model and a simpler next step.

This page gives developers a short overview of the relevant API surfaces and an application form for test or production access. Full documentation, export files, and interactive tooling stay on protected pages for approved users.

Apply for environment access View API surfaces Already approved? Open portal

API surfaces that are commonly relevant

The public page does not expose the full specification, but it shows the main areas typically used for mobile apps, partner solutions, and operational integrations.

Mobile API Authentication, tenant selection, 2FA, work orders, forms, documents, notifications, and device registration.
Control Tower API Operational status, telemetry, and control-oriented endpoints for external operations and monitoring environments.
Integration Suite Controlled ingestion and exchange of data with third parties, webhooks, and partner processes.
RUH partner API Bidirectional GET and PUT for unwanted incident reports. Partners call one central contract; FleetCore routes into the tenant that owns the RUH data.

RUH: central contract, tenant-bound data

A customer RUH API should not be a public per-tenant URL as the default. Auth, versioning, audit, and developer access live in central. Tenant context owns the reports and any outbound destination URL or keys when FleetCore calls the customer system.

Account first The API is not public. A FleetCore account, approved developer access, and a key issued to that account are required before any GET or PUT is accepted.
Inbound GET/PUT Partners read and update RUH through /api/partner/v1/ruh with X-Tenant-Id. One specification on /utvikler, account-bound keys, no implicit all-tenant access.
Outbound GET/PUT When the customer has their own RUH API, URL and credentials are bound per tenant in Integration Suite, but delivery still goes through the central retry, audit, and replay layer.
Direct tenant links only as exception On-prem or isolated networks can be exceptions. They are not the documented partner path.

How the process works

The flow is intentionally simple so it is clear what happens from the first contact until possible access to test and production.

1
Submit an application
Describe the solution, your contact point, and what the integration is meant to support.
2
Technical clarification
The use case, callback URL, and requested environment are reviewed before further access is opened.
3
Access to documentation and environments
Once approved, the relevant documentation and artifacts become available in the developer portal.
Public page: overview and application. Protected page: Swagger, OpenAPI, Postman, and typed client files.

Apply for test and production access

Submit details about the integration. You can request test access, production access, or both. Each environment is reviewed separately.

Test and production are reviewed separately. Full documentation becomes available in the authenticated developer portal after approval.