Version in english (You can find the German version below)
The purpose of the DKV product Enterprise API is to provide comprehensive billable data to customers.
The DKV data will be provided in a user-friendly JSON format, what simplifies the integration of provided data into various systems and make possible to manage and analyse the detailed data more efficiently.
The product Enterprise API consists of several individual APIs, which are currently grouped into following areas:
API Invoice data service provides only invoiced transactions and passages from consumptions of card/box transactions.
API Consumption data service provides invoiced & not invoiced transactions from consumptions of card/box transactions and toll passages, emobility and vehicle services, providing enriched data than on the invoice, enabling customers to forecast and analyze the consumption with a lot of detailed information. Contains as invoiced data and uninvoiced data
Master data API provides details for various customer-related data: DKV service cards and toll products.
Online Authorization data service API delivers the information on authorization requests of the past 24h. Regularly these authorization requests already contain detailed information on the products which were paid for.
Anyone interested can register on our APIM Developer Portal and subscribe to the product Enterprise API.
Please note: The subscription key from the Developer Portal is not sufficient to obtain your own data. Every customer needs a technical user with his own credentials.
The detailed information about APIs you find on our page: Enterprise APIs
Important: In any customer/user contact, the DKV Customer Service is the primary point of contact. The API Access cannot be requested via the API Portal.
The Customer Onboarding is required to use the Enterprise API. This process ensures that each customer receives personalized and secure access to our API, allowing us to maintain high security standards.
To retrieve of DKV data by the Enterprise API, follow these steps:
More detailes about the onboarding process you find below in the chapter Customer Onboarding
These credentials are necessary for authentication your API requests.
Each API user requires a technical user to access the API.
A technical user is a unit used to manage an API access for every customer.
Some more detailed information about technical user you find below in the chapter Customer Onboarding
Authentication is the process of verifying the identity of a user that wants to access the Enterpsise API. This ensures that only authorized users or systems can interact with your services.
Authentication involves the use of OAuth token.
Authorization defines what an authenticated user is allowed to do.
After identity verification, the system checks the permissions associated with that identity to determine which customer number(s) data can be retrieved for and whether use of the API is permitted for authorized transactions.
Each Entreprise API request follows a specific structure.
HTTP Method: POST
Endpoint (URL): Each API within Enterprise API has it’s own endpoint where the API can be accessed. Each endpoint corresponds to a particular resource.
The base URL remains the same https://api.dkv-mobility.com/e-api/, but the specific path changes depending on the API.
More detailed information about the Enterprise API requests can be found on our api page Enterprise APIs
Headers: Headers provide metadata about the request and are essential for authentication and content type.
Authorization: Includes OAuth token
Content-Type: Specifies the format of the data being sent or received (application/json).
Accept: Informs the server what format the client expects in the response (*/*)
Query Parameters: These parameters are used to filter, sort, and customize your request. Passed in the Endpoint to refine the request
Example: https://api.dkv-mobility.com/e-api/v2.0.0/transactions/tranactionDate?size=100&page=0&customerId=0000123456&endDate=2024-06-30&startDate=2024-06-01
Request Body
The request body is used for additional filtering of a requested data. Format: JSON.
Example for a POST request to filtering of only invoiced transactions:
{
"invoiceStatus": {
"in": [
"INVOICED"
]
}
}In our product Enterprise API, each API is assigned its own version number.
Version numbers help ensure that updates can be tracked and referenced easily.
Version Numbering: APIs are labeled with a version number that increments when significant changes are made .
Examples: v1.0.1, v2.0.0, v1.0
After sending the request, the API will respond with a response code and data in JSON format.
More detailed information about the Enterprise API response structure can be found on our api page Enterprise APIs
API response code indicates the status of a request made to a server and informs whether the request was successful or if there were any errors.
The code consists of a three-digit number and is divided into different categories:
2xx (Success): The request was successfully processed and data is returned.
4xx (Client Error): There was an issue with the request (e.g., incorrect parameters or missing authentication).
5xx (Server Error): The server encountered an issue processing the request.
More detailed information about error codes you find below in the chapter “Error handling”
Transaction datetime values in all Enterprise API responses will be displayed in UTC format.
Important:
In any customer/user contact, the DKV Customer Service is the primary point of contact. The API Access cannot be requested via the API Portal.
If the prospective API user is not a DKV customer yet, the user should get in touch with DKV Sales Team or DKV Customer serivce, to become a DKV customer, by signing all relevant documents and especially the general terms and conditions related to the usage of our services.
Request Submission: The customer initiates the process by contacting customer service.
Service Request Creation: Customer service opens a service request for the API onboarding.
Credentials Issuance (7-10 Days):
It typically takes 7-10 days for the customer to receive their API credentials. A new created technical user, client id and his subscription key is sent via email, and the client secret is delivered via SMS.
The onboarding email also includes:
An overview of how to use the client ID and client secret for authenticating API requests.
Examples of Request Structure: Sample API requests to illustrate how to properly format requests and include authentication details.
This information helps customers understand how to correctly authenticate and structure their API requests.
Customer must provide to the DKV Customer service following information:
main company name
main customer number
mobile phone number
other customer numbers, who will be able to retrieve the data with newly created technical user
further legal documentation to be signed
The attributes of every existing technical user can be changed, excepted technical user name itself.
The request for this can be made via DKV Customer Service, please use the technical username (NOT the clientId) as reference for requesting any change.
Additional customer numbers can also be assigned to existing technical user.
The request for this can made via DKV Customer Service, please use the technical username (NOT the clientId) as reference for requesting any change.
The following services are available currently for free use, which shall however change in 2025:
transactions and passages
master data: service cards
master data: toll products
Important: A service for delivering of online authorization data (OLA service) is not automatically accessible to all users.
Access is granted based on specific authorization processes and requirements.
Using of the OLA service requires special approval of the DKV Sales Lead.
DKV Customer Service is the primary point of contact also in this case.
Once the credentials are received, the customer can use the Try It feature to test API functionality before full integration.
The customer onboarding can be ordered in Matrix42:
Enterprise API Customer Connection
In the context of an API Management (APIM) developer portal, a
subscription for a product refers to an arrangement where a client
subscribes to any API as a “product” that groups together more
APIs.
It allows DKV to provide access to the documentation of subscribed products and enables the Try It feature.
Once subscribed, the user receives a unique subscription key, which must be selected in the Try It feature to test API requests.
This key is part of the authorization process for making test API requests.
The other kind of Subscription Key is generated by the DKV and you receive it by E-Mail along with other access credentials like client_id and client_secret.
The client sends the subscription key in the request header when making real (not a test) API call for retrieving his own data.
Header: ocp-apim-subscription-key
Value: 1234567890abcdef1234567890abcdef
The API server checks the subscription key to:
Ensure that the client has access to the API.
Enforce rate limits or usage quotas based on the subscription plan.
If the subscription key is missing or invalid, the server returns an error 401 Unauthorized.
{
"code": 401,
"errors": [
{
"message": "Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription.",
"field": null
}
]
}To ensure secure access to the Enterprise API, we utilize a combination of OAuth2 and subscription keys.
These mechanisms work together to authenticate and authorize API requests, safeguarding your data and ensuring that only authorized users can access the API.
OAuth2 Authentication
Each customer is provided with unique credentials, including a client ID (sent by E-mail) and client secret (sent by SMS), upon onboarding.
To authenticate, clients must first obtain an access token by making a request to our token endpoint using their credentials.
This access token is then included in the Authorization
header
(Authorization: Bearer <access_token>) of each API
request.
The token is only valid for 5 minutes, after which it expires and must be requested again.
Subscription Key
In addition to the token, a subscription key is required to authorize access to specific API resources.
The subscription key, which is issued during the onboarding process and sent by onboarding E-mail, must be included in the Ocp-Apim-Subscription-Key header of each API request.
This key helps us manage and monitor API usage, ensuring that requests are coming from valid and authorized subscriptions.
Subscriptions are issued only once and do not expire
Security Note
Ensure that both your credentials and subscription key are stored securely and not exposed in client-side code.
To obtain a token, follow these steps:
Token endpoint: https://my.dkv-mobility.com/auth/realms/enterprise-api/protocol/openid-connect/token
grant_type: client_credentials
client_id: Your client ID (sent by E-Mail)
client_secret: Your client secret (sent by SMS)
scope: openId
Example Token Request:
curl -v -X POST https://my.dkv-mobility.com/auth/realms/enterprise-api/protocol/openid-connect/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=client_credentials' \
-d 'client_id=[Your Unique client_id]' \
-d 'client_secret=[Your Unique client_secret]' \
-d 'scope=openid'If your request is successful, you will receive a response containing the access token, which typically looks like this:
{
"access_token": "<<CONTENT_OF_THE_JWT_TOKEN>>"
"expires_in": 300,
"refresh_expires_in": 0,
"token_type": "Bearer",
"id_token": "<<CONTENT_OF_THE_ID_TOKEN>>"
"not-before-policy": 0,
"scope": "openid"
}The access_token value is what you will use to authenticate your API requests.
Include the access token in the Authorization header of your API requests.
Example API Request:
curl -v -X POST https://api.dkv-mobility.com/e-api/v2.0.0/transactions/transactionDate?size=100&page=0&customerId=0000123456&endDate=2024-05-30&startDate=2024-05-01\
-H 'Authorization: bearer <<CONTENT_OF_THE_JWT_TOKEN>>'\
-H 'Content-Type: application/json' \
-H 'Content-Length: 0' \
-H 'ocp-apim-subscription-key: <<CONTENT_OF_THE_SUBSCRIPTION_KEY>>'Tokens have an expiration time (expires_in), so you need to handle token renewal or re-authentication as needed.
Verify Endpoint URL
Ensure you’re using the correct URL for the token endpoint. Check the API documentation for the precise endpoint and make sure there are no typos.
Check Request Headers
Make sure that the Content-Type header is set correctly to application/x-www-form-urlencoded.
Validate Credentials
Double-check that the client_id and client_secret you’re using are correct and active.
These values are case-sensitive and must match exactly what was provided during onboarding.Otherwise the authorization server denied the request
Review the error message returned by the server.
Common issues include:
Invalid Grant Type: Ensure grant_type is set to client_credentials.
Invalid Client ID/Secret: Verify the correctness of your credentials.
Missing or Invalid Parameters: Ensure all required parameters are included.
The authorization server could be temporarily unable to handle the request due to maintenance or other issues.
If the issue persists, contact the API Management Support team with detailed error information for assistance: api-management@dkv-mobility.com
An authorization token is a secure, encoded string issued after successful authentication, representing the user’s or system’s identity and permissions.
It’s used to grant access to authorized customer number(s) or services within an Enterprise API.
Once the token is issued, it is included in each request to prove that the client has the necessary authorization to retrieve the specific data of defined customers.
Tokens are commonly JSON Web Tokens (JWT), which consist of three parts:
Header: Contains metadata about the token (e.g., the type of token and the algorithm used for signing).
Payload: Holds claims or information about the user and their permissions.
Signature: Used to verify the token’s authenticity and ensure it hasn’t been tampered with.
Authorization tokens are generated by an authentication server after a user successfully authenticates (Auth 2.0 Client Credentials Flow).
The server encodes the user's identity and permissions into a token, which is then returned to the client.
This token must be included in API requests as a proof of authorization.
Here’s a breakdown of the fields in your token and what they represent.
The token requester is sometimes called the client.
{
"exp": 1725894657,
"iat": 1725894357,
"jti": "5e11fde3-f097-333a-8688-901ab8a449vv",
"iss": "https://my.dkv-mobility.com/auth/realms/enterprise-api",
"sub": "1230d38-59ac-446f-96a4-ebf0ad0bd515",
"typ": "Bearer",
"azp": "Test1",
"scope": "openid",
"AUTHORIZED_CUSTOMER_NRS": [
"0000111111",
"0000222222"
],
"MAIN_COMPANY_NAME": "DKV EURO SERVICE GmbH + Co. KG",
"clientId": "Test1",
"clientHost": "xxx.xxx.xxx.xx",
"TECHNICAL_USER_API_ROLES": [
"passages",
"transactions",
"fuelcardinformation",
"obuinformation",
"olaservice"
],
"TECHNICAL_USERNAME": "TEST User",
"CONTACT_EMAIL": "max.mustermann@step.com",
"MOB_NUMBER": "0049157834561",
"TECHNICAL_USER_PRODUCT": [
"DKV_EREPORTING_PREMIUM",
"DKV_EREPORTING"
],
"MAIN_CUSTOMER_NO": "0000111111",
"clientAddress": "xxx.xxx.xxx.xx",
"client_id": "Test1"
}Token Fields Explained:
exp (Expiration Time): This is a Unix timestamp indicating when the token will expire. After this time, the token will no longer be valid (e.g., 1725894657).
iat (Issued At): The Unix timestamp for when the token was created or issued.
jti (JWT ID): A unique identifier for the token
iss (Issuer): Identifies the issuer of the token, in this case, the URL of the authentication server (https://my.dkv-mobility.com/auth/realms/enterprise-api).
sub (Subject): Refers to the unique identifier of the user that the token is for (e.g., “1230d38-59ac-446f-96a4-ebf0ad0bd515”).
typ (Type): Indicates the type of token (“Bearer”) that are used for API authorization.
azp (Authorized Party): Identifies the client application that this token is intended for (e.g., “Test1”).
scope: Defines the scope of access granted by the token (e.g., “openid”).
AUTHORIZED_CUSTOMER_NRS: A list of customer numbers authorized to use this token, associated with the user
These numbers are verified when processing requests to ensure that the token holder has access to specific customer resources (e.g., “0000111111”, “0000222222”).
MAIN_COMPANY_NAME: The name of the main company associated with this token (e.g., “DKV EURO SERVICE GmbH + Co. KG”).
clientId: Identifies the client that is making the request (e.g., “Test1”).
clientHost: The IP address of the client making the request (e.g., “xxx.xxx.xxx.xx”).
TECHNICAL_USER_API_ROLES: A list of API roles that define what services the token holder is authorized to perform (e.g., “passages”, “transactions”, “fuelcardinformation”, “olaservice”).
Currently only olaservice changes whether it is enabled or disabled for API user.
All other services remain the same and permitted for all API users.__
TECHNICAL_USERNAME: The username of the technical user associated with the token requestor(e.g., “TEST User”).
CONTACT_EMAIL: The contact email address associated with the token requestor (e.g., “max.mustermann@step.com”).
MOB_NUMBER: The mobile phone number of the user (e.g., “0049157834561”).
TECHNICAL_USER_PRODUCT: A list of product cathegories that the technical user has access to (e.g., “DKV_EREPORTING_PREMIUM”, “DKV_EREPORTING”). Currently it’s a constant value.
MAIN_CUSTOMER_NO: The main customer number associated with the token requestor (e.g., “0000111111”).
clientAddress: The IP address of the client machine sending the request.
client_id: Another identifier for the client application making the request (e.g., “Test1”).
In Enterprise API, authorization involves comparing the content of the authorization token with the data in the request, such as the customer number and service access permissions.
Request Submission: The client sends a request that includes a customer number and an authorization token as a authorization header.
Token Validation: The API checks the token’s content, which includes the authorized customer number(s) and the services the token allows access to.
Comparison with Request Data:
The customer number in the request is compared with the authorized customer number(s) in the token.
The API also checks if the token allows access to the requested service (e.g., “ola” service).
Decision:
If the customer number in the request matches the authorized customer number in the token and the token allows access to the requested service, the request is processed.
If either the customer number or the service permission in the token does not match the request, the API will reject the request and return a 403 Forbidden error.
403 Error Example:
{
"code": 403,
"errors": [
{
"message": "Your API user does not have access to get data for customerId provided",
"field": "customerId"
}
]
}403 Forbidden error occurs if:
The customer number in the request does not match the number authorized in the token, or
The token does not grant permission to the requested service.
Define Objectives: Clearly outline the goals and benefits of integrating with the Enterprise API.
Review Documentation: Ensure you have access to comprehensive Enterprise API documentation, including endpoints, parameters, and response formats.
API Access: Obtain necessary credentials, such as client_id and subscription key (sent by email) and client_Secret (sent by sms), required for authentication and authorization.
Determine Scope: Decide which API endpoints and functionalities are relevant for your integration.
Plan for Error Handling: Develop strategies for managing and responding to potential errors or exceptions.
Authentication Method: Implement the required authentication mechanism (OAuth tokens).
Authorization Scope: Ensure that your API requests adhere to the permissions and scopes defined by the Enterprise API.
Secure Storage: Safeguard API credentials and tokens to prevent unauthorized access.
Monitor Updates: Regularly review the API changelog to stay informed about new features, enhancements, and breaking changes to the Enterprise API.
Update Integration: Adjust your integration as needed to accommodate new updates or changes to ensure compatibility and take advantage of new functionality.
Documentation of Changes: Keep track of how updates may affect your application and update your documentation and code accordingly.
Enterprise API use worldwide-adopted semantics of the HTTP Response Codes. More about that can be found here.
Transient error are the temporary ones. The perfect example of
transient error is the HTTP 503 Service Unavailable.
429 Too Many Requests
Each subscription has only some certain amount of requests per minute allowed. In case of this threshold is exceeded the HTTP 429 response code is returned.
500 Internal Service Error
This error may happen because of the unhandled error in the server code. No required retry from the client side is needed. If observed this situation will be handled by the DKV IT. Client should try to use the API later.
502 Bad Gateway
This error may happen because the BE temporarily can not be accessed on the network level. It’s recommended to apply exponential backoff retry in this case.
503 Service Unavailable
This error may happen because the BE is temporarily unavailable. It’s recommended to apply exponential backoff retry in this case.
504 Gateway Timeout
This error may happen because the BE was not able to respond within predefined timeout for the API. It’s recommended to apply exponential backoff retry in this case.
408 Request Timeout
This error shows that the API did not respond in the same speed as the client expected. API Consumers should not frequently see this error.
Non-transient errors are permantent ones. They require changes on the
client-side. The perfect examples of non-transient error are the
HTTP 400 Bad Request and
HTTP 401 Unathorized.
400 Bad Request
This error happens when the client’s request does not fit to the schema. It does not make sense to retry sending the same request when the response is HTTP 400. Client has to take care of fixing the request
401 Unauthorized
This error happens when the client’s request does not have valid authentication or authorization. It does not make sense to retry sending the same request when the response is HTTP 401.
All billed transactions can be retrieved in three ways:
Retrieve tranasctions data by invoice date.
Operation: fetch invoiced transactions
Retrieve transactions data filtered by invoice date.
Operation: Retrieve transactions data by invoice date
Retrieve transactions data filtered by transaction date with additional filter (in request body) by invoiceStatus = INVOICED
Operation: Retrieve transactions data by transaction date
All billed passages can be retrieved in three ways:
Retrieve passage data filtered by invoice date.
Operation: fetch invoiced transactions
Retrieve passage data filtered by invoice date.
Operation: Retrieve passages data by invoice date
Retrieve passages data filtered by passage end date with additional filter (in request body) by invoiceStatus = INVOICED
Retrieve transactions data filtered by transaction date with additional filter (in request body) by invoiceStatus = NOT_INVOICED
Retrieve passages data filtered by passage end date with additional filter (in request body) by invoiceStatus = NOT_INVOICED
Version in Deutsch
Der Zweck des DKV-Produkts Enterprise API besteht darin, den Kunden umfassende abrechnungsfähige Daten bereitzustellen.
Die DKV-Daten werden in einem benutzerfreundlichen JSON-Format zur Verfügung gestellt, was die Integration der bereitgestellten Daten in verschiedene Systeme vereinfacht und eine effizientere Verwaltung und Analyse der detaillierten Daten ermöglicht.
Das Produkt Enterprise API besteht aus mehreren einzelnen APIs, die derzeit in folgende Bereiche unterteilt sind:
API Invoice data service stellt nur abgerechnete Transaktionen und Passagen aus dem Verbrauch von Karten-/Boxtransaktionen bereit.
API Consumption data service bietet abgerechnete und nicht abgerechnete Transaktionen aus dem Verbrauch von Karten-/Boxtransaktionen, Mautpassagen, E-Mobilität und Fahrzeugdienstleistungen. Sie liefert angereicherte Daten, die über die auf der Rechnung enthaltenen Informationen hinausgehen und es den Kunden ermöglichen, den Verbrauch mit einer Vielzahl detaillierter Informationen vorherzusagen und zu analysieren. Sie enthält sowohl abgerechnete als auch nicht abgerechnete Daten.
Master data API bietet Details zu verschiedenen kundenbezogenen Daten: DKV-Servicekarten und Mautprodukte.
Online Authorization data API liefert Informationen zu Autorisierungsanfragen der letzten 24 Stunden. In der Regel enthalten diese Autorisierungsanfragen bereits detaillierte Informationen zu den Produkten, die bezahlt wurden.
Interessierte Personen können sich auf unserem APIM Developer Portal registrieren und das Produkt Enterprise API abonnieren.
Bitte beachten Sie: Der Abonnement-Schlüssel vom Developer Portal reicht nicht aus, um auf Ihre eigenen Daten zuzugreifen. Jeder Kunde benötigt einen technischen Benutzer mit eigenen Zugangsdaten.
Eine detallierte Information über alle APIs finden Sie auf unserer Seite: Enterprise APIs
Wichtig: Bei allen Kunden-/Nutzeranfragen ist der DKV Kundenservice der primäre Ansprechpartner. Der API-Zugang kann nicht über das API-Portal angefordert werden.
Eine Kundeanbindung(Onboarding) ist erforderlich, um die Enterprise API zu nutzen. Dieser Prozess stellt sicher, dass jeder Kunde personalisierten und sicheren Zugang zu unserer API erhält, wodurch wir hohe Sicherheitsstandards aufrechterhalten können.
Um DKV-Daten über die Enterprise API abzurufen, befolge diese Schritte:
Mehr Details zum Onboarding-Prozess findest du unten in dem Kapitel Kundenanbindung.
Erhalte Zugangsdaten: Nach Abschluss des Onboardings wird dein technischer Benutzer mit allen deinen Attributen (wie Firmenname, E-Mail, Mobilnummer etc.) erstellt, und du erhältst deine Authentifizierungsdaten per E-Mail und SMS. Diese Zugangsdaten sind notwendig, um deine API-Anfragen zu authentifizieren.
Integration starten: Verwende deine Zugangsdaten zur Authentifizierung und beginne mit der Integration der Enterprise API in deine Systeme. Weitere Informationen findest du in unserer API-Dokumentation, die detaillierte Anweisungen zu Endpunkten und zur Nutzung enthält.
Each API user requires a technical user to access the API.
A technical user is a unit used to manage an API access for every customer.
Jeder API-Nutzer benötigt einen technischen Benutzer, um auf die API zuzugreifen.
Ein technischer Benutzer ist eine Einheit, die verwendet wird, um den API-Zugang für jeden Kunden zu verwalten.
Weitere Informationen zu technischen Benutzern findest du aunten in dem Kapitel Kundenanbindung.
Authentifizierung ist der Prozess der überprüfung der Identität eines Nutzers, der auf die Enterprise API zugreifen möchte. Dies stellt sicher, dass nur autorisierte Nutzer oder Systeme mit deinen Diensten interagieren können.
Die Authentifizierung erfolgt durch die Verwendung eines OAuth-Tokens.
Autorisierung definiert, was ein authentifizierter Nutzer tun darf.
Nach der Identitätsüberprüfung überprüft das System die Berechtigungen, die mit dieser Identität verknüpft sind, um festzustellen, Daten welcher Kunden abgerufen werden können und ob die Nutzung der API für autorisierte Transaktionen erlaubt ist.
Jede Anfrage an die Enterprise API folgt einer spezifischen Struktur.
HTTP Methode: POST
Endpoint (URL): Jede API innerhalb der Enterprise API hat ihren eigenen Endpunkt, über den auf die API zugegriffen werden kann. Jeder Endpunkt entspricht einer bestimmten Ressource.
Die Basis-URL bleibt https://api.dkv-mobility.com/e-api/, aber der spezifische Pfad ändert sich je nach API.
Mehr Informationen über die Enterprise API-Anfragen findest du auf unserer API-Seite Enterprise APIs
Header: Header liefern Metadaten über die Anfrage und sind essenziell für die Authentifizierung und den Inhaltstyp.
Authorization: Enthält das OAuth-Token
Content-Type: Gibt das Format der gesendeten oder empfangenen Daten an (application/json)
Accept: Informiert den Server darüber, welches Format der Client in der Antwort erwartet (*/*)
Abfrageparameter(Query Parameters): Diese Parameter werden verwendet, um deine Anfrage zu filtern, zu sortieren und anzupassen. Sie werden im Endpunkt übergeben, um die Anfrage zu verfeinern.
Beispiel: https://api.dkv-mobility.com/e-api/v2.0.0/transactions/tranactionDate?size=100&page=0&customerId=0000123456&endDate=2024-06-30&startDate=2024-06-01
Anfrage-Body
Der Anfrage-Body wird für zusätzliche Filterung der angeforderten Daten verwendet. Format: JSON
Example for a POST request to filtering of only invoiced transactions:
{
"invoiceStatus": {
"in": [
"INVOICED"
]
}
}In dem Produkt Enterprise API hat jede API ihre eigene Versionsnummer.
Versionsnummern helfen dabei, Updates leicht nachzuverfolgen und zu referenzieren.
Versionsnummerierung: APIs werden mit einer Versionsnummer versehen, die sich erhöht, wenn signifikante änderungen vorgenommen werden.
Beispiele: v1.0.1, v2.0.0, v1.0
Nach dem Senden der Anfrage antwortet die API mit einem Antwortcode und Daten im JSON-Format.
Weitere Informationen zur Struktur der API-Antworten findest du auf unserer API-Seite Enterprise APIs
Antwortcode (response code)
Ein Antwortcode zeigt den Status einer Anfrage an einen Server an und informiert darüber, ob die Anfrage erfolgreich war oder ob Fehler aufgetreten sind.
Der Code besteht aus einer dreistelligen Zahl und ist in verschiedene Kategorien unterteilt:
2xx (Erfolg): Die Anfrage wurde erfolgreich verarbeitet und Daten werden zurückgegeben.
4xx (Client-Fehler): Es gab ein Problem mit der Anfrage (z. B. falsche Parameter oder fehlende Authentifizierung).
5xx (Server-Fehler): Der Server hatte ein Problem bei der Verarbeitung der Anfrage.
Weitere Informationen zu Fehlercodes findest du auf unserer Seite zur Fehlerbehandlung: Enterprise API Error handling
Datumsangaben zu Transaktionen in allen Antworten der Enterprise API werden im UTC-Format angezeigt.
Wichtig:
Bei jedem Kunden- oder Benutzerkontakt ist der DKV Kundenservice der primäre Ansprechpartner. Der API-Zugang kann nicht über das API-Portal angefordert werden.
Falls der potenzielle API-Nutzer noch kein DKV-Kunde ist, sollte er sich mit dem DKV-Vertriebsteam oder dem DKV-Kundenservice in Verbindung setzen, um DKV-Kunde zu werden.
Dazu ist es notwendig, alle relevanten Dokumente, insbesondere die allgemeinen Geschäftsbedingungen zur Nutzung unserer Dienste, zu unterzeichnen.
Antragstellung: Der Kunde beginnt den Prozess, indem er den Kundenservice kontaktiert..
Erstellung eines Serviceauftrags: Der Kundenservice eröffnet einen Serviceauftrag für das API-Onboarding.
Verschicken der Zugangsdaten (7-10 Tage):
Es dauert in der Regel 7-10 Tage, bis der Kunde seine API-Zugangsdaten erhält.
Ein neu erstellter technischer Benutzer, die Client-ID und der Subscription Key werden per E-Mail versandt, während das Client Secret per SMS übermittelt wird.
The onboarding E-Mail also includes:
Eine übersicht, wie die Client-ID und das Client Secret zur Authentifizierung von API-Anfragen genutzt werden..
Beispiele für die Struktur von Anfragen: Musteranfragen, die veranschaulichen, wie Anfragen richtig formatiert und Authentifizierungsdetails eingebunden werden.
Diese Informationen helfen den Kunden, zu verstehen, wie sie ihre API-Anfragen korrekt authentifizieren und strukturieren.
Der Kunde muss dem DKV Kundenservice folgende Informationen bereitstellen:
Hauptfirmenname
Hauptkundennummer
E-Mail-Adresse
Mobiltelefonnummerr
Weitere Kundennummern, die mit dem neu erstellten technischen Benutzer Daten abrufen können
Weitere rechtliche Dokumente zur Unterschrift
Die Attribute jedes bestehenden technischen Benutzers können geändert werden, mit Ausnahme des technischen Benutzernamens selbst.
Die Anfrage hierfür kann über den DKV Kundenservice gestellt werden, bitte verwenden Sie den technischen Benutzernamen (NICHT die Client-ID) als Referenz, um änderungen anzufordern.
Zusätzliche Kundennummern können ebenfalls einem bestehenden technischen Benutzer zugeordnet werden.
Die Anfrage dafür kann über den DKV Kundenservice gestellt werden, bitte verwenden Sie den technischen Benutzernamen (NICHT die Client-ID) als Referenz, um änderungen anzufordern.
Die folgenden Services sind derzeit kostenlos nutzbar, dies wird sich jedoch im Jahr 2025 ändern:
Transaktionen und Passagen
Kundenstammdaten - Servicekarten
Kundenstammdaten - Mautprodukte
Wichtig: Ein Service zur Bereitstellung von Online-Autorisierungsdaten (OLA-Service) ist nicht automatisch für alle Nutzer zugänglich.
Der Zugang wird basierend auf spezifischen Autorisierungsprozessen und Anforderungen gewährt.
Die Nutzung des OLA-Services erfordert eine spezielle Genehmigung durch den DKV-Vertriebsleiter.
Der DKV Kundenservice ist auch in diesem Fall der primäre Ansprechpartner.
Sobald die Zugangsdaten vorliegen, kann der Kunde die Try It -Funktion nutzen, um die API-Funktionalität vor der vollständigen Integration zu testen.
Eine Anbindung (Onboarding) kann mit einem Service request in Matrix42 beantragt werden:
Enterprise API Kunden Anbindung
Im Kontext eines API-Management (APIM)-Entwicklerportals bezieht sich ein Abonnement für ein Produkt auf eine Vereinbarung, bei der sich ein Kunde auf eine Enterprise-API als „Produkt“ abonniert, das mehrere APIs gruppiert.
Dadurch kann DKV dem Kunden Zugriff auf die Dokumentation der abonnierten Produkte gewähren und die Nutzung der Try It-Funktion ermöglichen.
Sobald der Kunde abonniert ist, erhält er einen eindeutigen Abonnement-Schlüssel, der in der Try It-Funktion ausgewählt werden muss, um API-Anfragen zu testen.
Dieser Schlüssel ist Teil des Authentifizierungsprozesses für die Durchführung von Test-API -Anfragen.
Ein anderer Abonnement-Schlüssel wird von DKV generiert und Ihnen zusammen mit anderen Zugangsdaten wie client_id und client_secret per E-Mail zugeschickt.
Der Kunde sendet den Abonnement-Schlüssel im Header der Anfrage, wenn er eine echte (keine Test-) API-Anfrage zur Abfrage seiner eigenen Daten stellt.
Header: ocp-apim-subscription-key
Wert: 1234567890abcdef1234567890abcdef
Der API-Server prüft den Abonnement-Schlüssel, um:
Sicherzustellen, dass der Kunde Zugang zur API hat.
Nutzungsbegrenzungen oder Quoten gemäß dem Abonnementplan durchzusetzen.
Falls der Abonnement-Schlüssel fehlt oder ungültig ist, gibt der Server einen Fehler 401 Unauthorized zurück.
{
"code": 401,
"errors": [
{
"message": "Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription.",
"field": null
}
]
}Um einen sicheren Zugriff auf die Enterprise API zu gewährleisten, nutzen wir eine Kombination aus OAuth2 und Abonnementschlüsseln.
Diese Mechanismen arbeiten zusammen, um API-Anfragen zu authentifizieren und zu autorisieren, Ihre Daten zu schützen und sicherzustellen, dass nur autorisierte Benutzer auf die API zugreifen können.
OAuth2-Authentifizierung
Jeder Kunde erhält beim Onboarding eindeutige Zugangsdaten, einschließlich Client-ID (per E-Mail gesendet) und Client-Secret (per SMS gesendet).
Um sich zu authentifizieren, müssen sich die Kunden zunächst ein Zugriffstoken beschaffen, indem sie eine Anfrage an unseren Token-Endpunkt mit ihren Zugangsdaten stellen.
Dieses Zugriffstoken wird dann in den Authorization-Header (Authorization: Bearer <access_token>) jeder API-Anfrage eingefügt.
Das Token ist nur 5 Minuten gültig, danach läuft es ab und muss erneut angefordert werden.
Abonnementschlüssel (Subscription Key)
Zusätzlich zum Token ist ein Abonnementschlüssel (Subscription Key) erforderlich, um den Zugriff auf bestimmte API-Ressourcen zu autorisieren.
Der Abonnementschlüssel, der während des Onboarding-Prozesses ausgestellt und per Onboarding-E-Mail gesendet wird, muss ein header ocp-apim-subscription-key jeder API-Anfrage eingefügt werden.
Dieser Schlüssel hilft uns, die API-Nutzung zu verwalten und zu überwachen und sicherzustellen, dass Anfragen von gültigen und autorisierten Abonnements stammen.
Abonnementschlüssel wird nur einmal ausgegeben und läuft nicht ab.
Sicherheitshinweis
Stellen Sie sicher, dass sowohl Ihre Zugangsdaten als auch der Abonnementschlüssel sicher aufbewahrt und nicht im clientseitigen Code offengelegt werden.
Um ein Token zu erhalten, befolgen Sie diese Schritte:
Token-Endpunkt: https://my.dkv-mobility.com/auth/realms/enterprise-api/protocol/openid-connect/token
grant_type: client_credentials
client_id: Your client ID (sent by E-Mail)
client_secret: Your client secret (sent by SMS)
scope: openId
Beispiel für eine Token-Anfrage:
curl -v -X POST https://my.dkv-mobility.com/auth/realms/enterprise-api/protocol/openid-connect/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=client_credentials' \
-d 'client_id=[Your Unique client_id]' \
-d 'client_secret=[Your Unique client_secret]' \
-d 'scope=openid'Wenn Ihre Anfrage erfolgreich war, erhalten Sie eine Antwort mit dem Zugriffstoken, das typischerweise so aussieht:
{
"access_token": "<<CONTENT_OF_THE_JWT_TOKEN>>"
"expires_in": 300,
"refresh_expires_in": 0,
"token_type": "Bearer",
"id_token": "<<CONTENT_OF_THE_ID_TOKEN>>"
"not-before-policy": 0,
"scope": "openid"
}Der access_token-Wert ist das, was Sie zur Authentifizierung Ihrer API-Anfragen verwenden.
Fügen Sie das Zugriffstoken in den Authorization-Header Ihrer API-Anfragen ein.
Beispiel für eine API-Anfrage:
curl -v -X POST https://api.dkv-mobility.com/e-api/v2.0.0/transactions/transactionDate?size=100&page=0&customerId=0000123456&endDate=2024-05-30&startDate=2024-05-01\
-H 'Authorization: bearer <<CONTENT_OF_THE_JWT_TOKEN>>'\
-H 'Content-Type: application/json' \
-H 'Content-Length: 0' \
-H 'ocp-apim-subscription-key: <<CONTENT_OF_THE_SUBSCRIPTION_KEY>>'Tokens haben eine Ablaufzeit (expires_in), daher müssen Sie die Token-Erneuerung oder eine erneute Authentifizierung bei Bedarf verwalten.
überprüfen Sie den Endpunkt-URL
Stellen Sie sicher, dass Sie die korrekte URL für den Token-Endpunkt verwenden. überprüfen Sie die API-Dokumentation für den genauen Endpunkt und achten Sie darauf, dass keine Tippfehler vorliegen.
Prüfen Sie die Anfrage-Header
Stellen Sie sicher, dass der _Content-Type-_Header korrekt auf application/x-www-form-urlencoded gesetzt ist.
Zugangsdaten validieren
überprüfen Sie, ob die verwendete client_id und client_secret korrekt und aktiv sind.
Diese Werte sind groß-/klein-schreibungssensitiv und müssen exakt mit den Angaben beim Onboarding übereinstimmen. Andernfalls lehnt der Autorisierungsserver die Anfrage ab.
überprüfen Sie die Fehlermeldung, die vom Server zurückgegeben wird
Häufige Probleme umfassen:
Ungültiger Grant-Typ: Stellen Sie sicher, dass grant_type auf client_credentials gesetzt ist.
Ungültige Client-ID/Secret: überprüfen Sie die Richtigkeit Ihrer Zugangsdaten.
Fehlende oder ungültige Parameter: Stellen Sie sicher, dass alle erforderlichen Parameter enthalten sind.
Der Autorisierungsserver könnte vorübergehend nicht in der Lage sein, die Anfrage aufgrund von Wartungsarbeiten oder anderen Problemen zu verarbeiten.
Wenn das Problem weiterhin besteht, kontaktieren Sie das API-Management-Supportteam mit detaillierten Fehlerinformationen: api-management@dkv-mobility.com
Ein Autorisierungstoken ist eine sichere, codierte Zeichenfolge, die nach erfolgreicher Authentifizierung ausgestellt wird und die Identität und Berechtigungen des Benutzers oder Systems darstellt.
Es wird verwendet, um den Zugriff auf autorisierte Kundennummern oder Dienste innerhalb einer Enterprise-API zu gewähren.
Sobald das Token ausgestellt ist, wird es in jeder Anfrage verwendet, um zu beweisen, dass der Client die erforderliche Autorisierung besitzt, um auf die spezifischen Daten der definierten Kunden zuzugreifen.
Tokens ist ein JSON Web Tokens (JWT), der aus drei Teilen besteht:
Header: Enthält Metadaten über das Token (z.B. den Token-Typ und den Algorithmus, der für die Signatur verwendet wird).
Payload: Holds claims or information about the user and their permissions.Payload: Enthält Ansprüche oder Informationen über den Benutzer und seine Berechtigungen.
Signatur: Wird verwendet, um die Authentizität des Tokens zu überprüfen und sicherzustellen, dass es nicht manipuliert wurd
Autorisierungstoken wird von einem Authentifizierungsserver erstellt, nachdem sich ein Benutzer erfolgreich authentifiziert hat (OAuth 2.0 Client Credentials Flow).
Der Server codiert die Identität und Berechtigungen des Benutzers in einem Token, das dann an den Client zurückgegeben wird.
Dieses Token muss in API-Anfragen als Nachweis der Autorisierung enthalten sein.
Hier ist eine übersicht der Felder in Ihrem Token und deren Bedeutung.
Der Token-Anforderer wird hier als „Client“ bezeichnet.
{
"exp": 1725894657,
"iat": 1725894357,
"jti": "5e11fde3-f097-333a-8688-901ab8a449vv",
"iss": "https://my.dkv-mobility.com/auth/realms/enterprise-api",
"sub": "1230d38-59ac-446f-96a4-ebf0ad0bd515",
"typ": "Bearer",
"azp": "Test1",
"scope": "openid",
"AUTHORIZED_CUSTOMER_NRS": [
"0000111111",
"0000222222"
],
"MAIN_COMPANY_NAME": "DKV EURO SERVICE GmbH + Co. KG",
"clientId": "Test1",
"clientHost": "xxx.xxx.xxx.xx",
"TECHNICAL_USER_API_ROLES": [
"passages",
"transactions",
"fuelcardinformation",
"obuinformation",
"olaservice"
],
"TECHNICAL_USERNAME": "TEST User",
"CONTACT_EMAIL": "max.mustermann@step.com",
"MOB_NUMBER": "0049157834561",
"TECHNICAL_USER_PRODUCT": [
"DKV_EREPORTING_PREMIUM",
"DKV_EREPORTING"
],
"MAIN_CUSTOMER_NO": "0000111111",
"clientAddress": "xxx.xxx.xxx.xx",
"client_id": "Test1"
}exp (Ablaufzeit): Ein Unix-Zeitstempel, der angibt, wann das Token abläuft. Nach diesem Zeitpunkt ist das Token nicht mehr gültig (z. B. 1725894657).
iat (Ausgestellt am): Der Unix-Zeitstempel, wann das Token erstellt oder ausgegeben wurde.
jti (JWT ID): Eine eindeutige Kennung für das Token.
iss (Issuer): Gibt den Herausgeber des Tokens an, in diesem Fall die URL des Authentifizierungsservers (https://my.dkv-mobility.com/auth/realms/enterprise-api).
sub (Subject): Bezieht sich auf die eindeutige Kennung des Benutzers, für den das Token bestimmt ist (z. B. „1230d38-59ac-446f-96a4-ebf0ad0bd515“).
typ (Typ): Gibt den Typ des Tokens an („Bearer“), das für die API-Autorisierung verwendet wird.
azp (Autorisierte Partei): Identifiziert die Client-Anwendung, für die dieses Token bestimmt ist (z. B. „Test1“).
scope: Definiert den Umfang des Zugriffs, der durch das Token gewährt wird (z. B. „openid“).
AUTHORIZED_CUSTOMER_NRS: Eine Liste der Kundennummern, die zur Verwendung dieses Tokens berechtigt sind und mit dem Benutzer verknüpft sind.
Diese Nummern werden bei der Verarbeitung von Anfragen überprüft, um sicherzustellen, dass der Tokeninhaber Zugriff auf bestimmte Kundenressourcen hat (z. B. „0000111111“, „0000222222“).
MAIN_COMPANY_NAME: Der Name des Hauptunternehmens, das mit diesem Token verknüpft ist (z. B. „DKV EURO SERVICE GmbH + Co. KG“).
clientId: Identifiziert den Client, der die Anfrage stellt (z. B. „Test1“).
clientHost: Die IP-Adresse des Clients, der die Anfrage stellt (z. B. „xxx.xxx.xxx.xx“).
TECHNICAL_USER_API_ROLES: Eine Liste der API-Rollen, die definiert, welche Dienste der Tokeninhaber ausführen darf (z. B. „passages“, „transactions“, „fuelcardinformation“, „olaservice“ etc.). Derzeit ändert sich nur „olaservice“, ob es für den API-Benutzer aktiviert oder deaktiviert ist. Alle anderen Dienste bleiben gleich und sind für alle API-Benutzer erlaubt.
TECHNICAL_USERNAME: Der Benutzername des technischen Benutzers, der mit dem Token-Anforderer verknüpft ist (z. B. „TEST User“).
CONTACT_EMAIL: Die Kontakt-E-Mail-Adresse, die mit dem Token-Anforderer verknüpft ist (z. B. „max.mustermann@step.com“).
MOB_NUMBER: Die Mobiltelefonnummer des Benutzers (z. B. „0049157834561“).
TECHNICAL_USER_PRODUCT: Eine Liste der Produktkategorien, auf die der technische Benutzer Zugriff hat (z. B. „DKV_EREPORTING_PREMIUM“, „DKV_EREPORTING“). Derzeit ist dies ein konstanter Wert.
MAIN_CUSTOMER_NO: Die Hauptkundennummer, die mit dem Token-Anforderer verknüpft ist (z. B. „0000111111“).
clientAddress: Die IP-Adresse des Client-Rechners, der die Anfrage sendet.
client_id: Eine weitere Kennung für die Client-Anwendung, die die Anfrage stellt (z. B. „Test1“).
Die Autorisierung In der Enterprise API beinhaltet den Vergleich des Inhalts des Autorisierungstokens mit den Daten in der Anfrage, wie z. B. der Kundennummer und den Zugriffsberechtigungen für den Service
Anfrage (API request) schicken: Der Client sendet eine Anfrage, die eine Kundennummer und ein Autorisierungstoken (als Autorisierungsheader) enthält.
Token-Validierung: Die API überprüft den Inhalt des Tokens, der die autorisierten Kundennummern und die Services enthält, auf die das Token Zugriff gewährt.
Vergleich mit Anfragedaten:
Die Kundennummer in der Anfrage wird mit den autorisierten Kundennummer(n) im Token verglichen.
Die API überprüft auch, ob das Token Zugriff auf den angeforderten Dienst (z. B. „olaservice“) gewährt.
Entscheidung:
Wenn die Kundennummer in der Anfrage mit der autorisierten Kundennummer im Token übereinstimmt und das Token Zugriff auf den angeforderten Service gewährt, wird die Anfrage verarbeitet.
Wenn entweder die Kundennummer oder die Serviceberechtigung im Token nicht mit der Anfrage übereinstimmt, lehnt die API die Anfrage ab und gibt einen 403 Forbidden-Fehler zurück.
Beispiel für einen 403-Fehler:
{
"code": 403,
"errors": [
{
"message": "Your API user does not have access to get data for customerId provided",
"field": "customerId"
}
]
}Ein 403 Forbidden-Fehler tritt auf, wenn:
Die Kundennummer in der Anfrage nicht mit der im Token autorisierten Nummer übereinstimmt, oder
Das Token keine Berechtigung für den angeforderten Service gewährt.
Ziele definieren: Legen Sie klar die Ziele und Vorteile der Integration mit der Enterprise API fest.
Dokumentation überprüfen: Stellen Sie sicher, dass Sie Zugriff auf umfassende Dokumentationen der Enterprise API haben, einschließlich Endpunkten, Parametern und Antwortformaten.
API-Zugriff: Erhalten Sie die erforderlichen Anmeldeinformationen, wie client_id und Abonnement(subscription)-schlüssel (per E-Mail gesendet) sowie client_secret (per SMS gesendet), die für die Authentifizierung und Autorisierung benötigt werden.
Umfang bestimmen: Entscheiden Sie, welche API-Endpunkte und Funktionen für Ihre Integration relevant sind.
Planung für Fehlerbehandlung: Entwickeln Sie Strategien für den Umgang mit und die Reaktion auf mögliche Fehler oder Ausnahmen.
Authentifizierungsmethode: Implementieren Sie den erforderlichen Authentifizierungsmechanismus (OAuth-Token).
Autorisierungsumfang: Stellen Sie sicher, dass Ihre API-Anfragen den Berechtigungen und Geltungsbereichen entsprechen, die von der Enterprise API definiert sind.
Sichere Speicherung: Schützen Sie die API-Anmeldeinformationen und Token, um unbefugten Zugriff zu verhindern.
Updates überwachen: überprüfen Sie regelmäßig das API changelog , um über neue Funktionen, Verbesserungen und breaking Changes der Enterprise API informiert zu bleiben.
Integration aktualisieren: Passen Sie Ihre Integration bei Bedarf an, um neue Updates oder änderungen zu berücksichtigen und sicherzustellen, dass die Kompatibilität gewahrt bleibt und neue Funktionen genutzt werden.
Dokumentation der änderungen: Behalten Sie im Auge, wie Updates Ihre Anwendung beeinflussen können, und aktualisieren Sie Ihre Dokumentation und Ihren Code entsprechend.
Die Enterprise API verwendet weltweit anerkannte Semantiken der HTTP-Antwortcodes. Weitere Informationen dazu finden Sie here.
Temporäre Fehler sind vorübergehende Fehler. Ein perfektes Beispiel für einen temporären Fehler ist der HTTP 503 Service Unavailable.
429 Too Many Requests
Jede Abonnement (subscription) hat nur eine bestimmte Anzahl von Anfragen pro Minute, die erlaubt sind. Wenn dieser Schwellenwert überschritten wird, wird der HTTP 429-Antwortcode Zu viele Anfragen zurückgegeben.
500 Internal Service Error
Dieser Fehler kann auftreten, wenn ein unbehandelter Fehler auf der Server-Seite aufgetreten ist. Von der Client-Seite ist kein erforderliches erneutes Senden nötig.
DKV IT wird diese Situation bemerken und schnell handeln. Der Client sollte versuchen, die API Anfrage später zu senden.
502 Bad Gateway
Dieser Fehler kann auftreten, wenn das Backend vorübergehend auf Netzwerkebene nicht erreichbar ist. In diesem Fall wird empfohlen, einen Retry-Mechanismus anzuwenden.
503 Service Unavailable
Dieser Fehler kann auftreten, wenn das Backend vorübergehend nicht verfügbar ist. In diesem Fall wird empfohlen, einen Retry-Mechanismus anzuwenden.
504 Gateway Timeout
Dieser Fehler kann auftreten, wenn das Backend nicht in der vorgegebenen Zeit eine API-Antwort geschickt hat. In diesem Fall wird empfohlen, einen Retry-Mechanismus anzuwenden.
408 Request Timeout
Dieser Fehler zeigt, dass der Client die API-Anfrage beendet hat, bevor die API reagiert hat.
Diese fehler erfordern änderungen auf der Client-Seite. Perfekte
Beispiele für nicht-temporäre Fehler sind
HTTP 400 Bad Request und
HTTP 401 Unathorized.
400 Bad Request
Dieser Fehler tritt auf, wenn die Anfrage des Clients nicht der Anfrage-Schema entspricht. Es macht wenig Sinn, dieselbe Anfrage erneut zu senden, wenn die Antwort HTTP 400 zurückkommt.
Der Client soll sich um die Fehlerbehebung kümmern.
401 Unauthorized
Dieser Fehler tritt auf, wenn die Anfrage des Clients keine gültige Authentifizierung oder Autorisierung hat.
Es macht wenig Sinn, dieselbe Anfrage erneut zu senden, wenn die Antwort HTTP 401 zurückkommt.
Alle abgerechneten Transaktionen können auf drei Arten abgerufen werden:
Abrufen von Transaktionsdaten nach Rechnungsdatum.
Operation: fetch invoiced transactions
Abrufen von Transaktionsdaten, gefiltert nach Rechnungsdatum.
Operation: Retrieve transactions data by invoice date
Abrufen von Transaktionsdaten, gefiltert nach Transaktionsdatum mit zusätzlichem Filter (in request body) für invoiceStatus = INVOICED.
Operation: Retrieve transactions data by transaction date
Alle abgerechneten Passagen können auf drei Arten abgerufen werden:
Abrufen von Passagedaten nach Rechnungsdatum.
Operation: fetch invoiced transactions
Abrufen von Passagedaten, gefiltert nach Rechnungsdatum.
Operation: Retrieve passages data by invoice date
Abrufen von Passagedaten, gefiltert nach Passage-Enddatum mit zusätzlichem Filter (in request body) nach invoiceStatus = INVOICED.
Operation: Retrieve passages data by passage end date
Rufen Sie Transaktionsdaten ab, gefiltert nach dem Transaktionsdatum, mit einem zusätzlichen Filter (im Request-Body) für invoiceStatus = NOT_INVOICED.
Rufen Sie Passagendaten ab, gefiltert nach dem Passage-Enddatum, mit einem zusätzlichen Filter (im Request-Body) für invoiceStatus = NOT_INVOICED.