Test

Hi Irmina,

Thank you, that's very helpful. Before I ask your Customer Service
colleagues to make the changes, I need to confirm one thing so the
setup works end to end.

For each payer account, can the invoice email be delivered to a single
address that we nominate - efaktury@schubert.cz - regardless of the
contact currently registered on the account? And can all nine payer
accounts be set to deliver to that same address?

Two details that matter for how we process them automatically:
- Is the invoice sent as a PDF attachment on the email, or as a link
to download?
- Is it one email per invoice, or a single email/statement per period?

If directing all nine to efaktury@schubert.cz is possible, we'd like to
enable it for all nine. Two process questions: is this something we can
change ourselves in Configuration Manager, or does it have to be
actioned by your Customer Service team? And who needs to authorize it -
the accounts are held by the Schubert group, so I can arrange
authorization from their side if required.

For reference, the nine payer accounts in scope:
- Michael Schubert - CZ00000304
- Schubert partner a.s. - CZ00003118
- VEJCE CZ s.r.o. - CZ00007040
- REALIT INVESTMENT S.R.O. - CZ00009677
- SCHUBERT PEKARNA S.R.O. - CZ56892471
- AGRO PRODUKCE s.r.o. - CZ56892852
- JERABEK & VODRAZKA - CZ56893979
- Realit investment Praha s.r.o. - CZ56917687
- MSV REAL GROUP s.r.o. - CZ56917691

Thanks,
Filip

Since creating our app "Benelux EV Charger Map" (approved, product: B2B EV Locations), every call to GET https://api-test.shell.com/locations/v1/ev fails. Steps: 1) POST /v1/oauth/token with our client credentials succeeds and returns a token. 2) GET /locations/v1/ev?pageNumber=1&perPage=250 with Authorization Bearer token and unique RequestId UUID header. 3) Response is always: fault "Execution of ServiceCallout SC-EV-TokenCall failed. Reason: ResponseCode 504 is treated as error" (errorcode steps.servicecallout.ExecutionFailed). Observed consistently on 25 and 26 July 2026, many attempts with fresh tokens from multiple networks. API Status shows EV Public Locations operational; our app shows Approved in My Apps. Could you check whether our app is fully provisioned for the EV Locations backend and advise what is needed to get /ev working? Account: whendriksen25@gmail.com. Thank you.

Hello Shell Developer Support,

OAuth token generation works correctly for my Consumer Key on both /v1/oauth/token and /v2/oauth/token (grant_type=client_credentials, valid access_token returned). However, every functional call fails. I tested systematically against the sandbox (api-test.shell.com):

GET /ev/v2/locations/nearby → 401, code: E0003, "unable to authenticate request"
GET /locations/v1/ev/nearby → 500, "Execution of ServiceCallout SC-EV-TokenCall failed. Reason: ResponseCode 504 is treated as error", errorcode: steps.servicecallout.ExecutionFailed
GET /ev/v1/locations/nearby → 500, same SC-EV-TokenCall / 504 error
GET /ds/ev/v1/locations/nearby → 401

Notably, the 500 occurs on exactly the paths my key appears to be authorized for — it looks like an internal token callout inside the test gateway (SC-EV-TokenCall) is timing out with a 504, rather than a problem on my side.

In my Developer Portal app, the following API products are currently enabled: B2B EV Locations and DS-Mobility-EV. I do not see an "EV Public Locations" product listed to subscribe to.

Could you please clarify:

Which API product must my Consumer Key be subscribed to in order to retrieve location and tariff data (including roaming partner locations) — B2B EV Locations, DS-Mobility-EV, or something else?
Why the internal SC-EV-TokenCall fails with a 504 (steps.servicecallout.ExecutionFailed) in the test environment on the paths I appear to be authorized for?
Whether test/sandbox credentials are sufficient to retrieve real data, or whether production credentials are required.

Consumer Key: CQwTRiuIu53sRWbMnMfLnI4nhl46ytDc
Example failed RequestId (E0003): 47af20be-e56a-4bea-80d2-65a8c7e72e0f

Thank you,
Jan

With ladestopp.de, we are developing a Europe-wide EV route and charging planner.
We already have most of the necessary information from the national Access Points (NAPs). Obtaining pricing for your company-owned charging stations is not an issue either; however, roaming rates present a challenge. No one (except Allego) makes this data readily available—or at least, obtaining it requires considerable effort just to get the information legally (e.g., from EnBW and Vattenfall). Since Shell has such an extensive roaming network (I have personally used the German Shell app to charge on Menorca), it would be exciting to access this information via your APIs.

But your website stated we need an account number to use the API.
Interestingly after log off and log on this message was gone, and our intial password was not working, so I had to change it (I changed it to te initial one and it worked!).

Best regards

Jan Wurl

We're integrating the EV Public Locations API (v2.1.2) into our app, SparkShare, using UAT credentials. Our app shows the "EV Public Locations API" product as Approved in the developer portal, but calls to the resource are being rejected.

Details:

Environment: UAT (api-test.shell.com)
Client ID: [your client_id]
Token request to /v1/oauth/token: succeeds, valid bearer token issued
Request to GET /ev/v2/locations: fails with HTTP 401
Error body: code: E0003, message: "Unauthorized", description: "unable to authenticate request"
Request ID from the failed call: 65c8ccf2-649f-4298-ba6b-abc1e26f108e

Since token issuance works but the resource call is rejected despite the product showing Approved, it looks like the subscription approval may not have propagated to the gateway's resource-level access control, or there's an additional entitlement step we're missing. Could you check the ACL/entitlement status for this client on /v2/locations and let us know what's needed to resolve it?

Happy to provide any further detail needed.

We are integrating our internal fleet management web application with Shell's Fleet Transaction Data API to automatically retrieve fuel refill/transaction records for our Shell fleet cards. Please advise on obtaining OAuth 2.0 API credentials (client ID/secret) and confirm which environment (sandbox/production) we should start with. Our Fleet account number is TH00013977 (ATHIPAT TOUR LTD PART). Note: we have also submitted a related ticket (Case ID 10689173) requesting a second fleet account (TH00013978, NEW ATIPAT CO LTD) be linked to the same integration/app "Atipat Fleet Fuel Data Integration".

Follow-up to our previous request for Fleet Transaction Data API access (Fleet account TH00013977, app "Atipat Fleet Fuel Data Integration"). We have a second company/fleet account that also needs to be linked to the same integration: TH00013978 (NEW ATIPAT CO LTD). Please enable access to Fleet Transaction Data API for this account as well, associated with the same app/consumer key so we can retrieve transaction data for both accounts (ideally via the multipayerspricedtransactions endpoint).

We are integrating our internal fleet management web application with Shell's Fleet Transaction Data API to automatically retrieve fuel refill/transaction records for our Shell fleet cards. Please advise on obtaining OAuth 2.0 API credentials (client ID/secret) and confirm which environment (sandbox/production) we should start with. Our Fleet account number is TH00013977.

Following up on case 10269013 (B2B Mobility Invoice, Test), which was
resolved before I replied. Apologies for the delay.

I am integrating invoice retrieval on behalf of the Schubert group, an
existing Shell Fleet Solutions customer in the Czech Republic, covering nine
payer numbers under one corporate umbrella. Today someone logs into Fleet Hub
each month and downloads the invoices manually, one account at a time.

First, a question that may remove the need for API access entirely:

Can invoice delivery by email be configured per payer number, so that invoice
PDFs are sent automatically to a single address when issued? If that is
possible for these nine accounts, it would meet our need and we would not
need API access at all.

If email delivery is not available for these accounts, we would like to
proceed with the API, and I have the following questions.

On the contract:
- The FAQ states that an existing Shell customer new to API usage signs an
API addendum to their existing agreement. Is that the route here, and can
you send the addendum or a summary of its terms?
- The FAQ also states production usage is typically subject to a fee. What is
the fee for the B2B Mobility Invoice API at this volume — nine payers, one
invoice retrieval run per month?
- These nine payers are separate legal entities under one umbrella. Is a
single addendum sufficient, or does each entity sign separately?
- What is the typical timeline from signature to production access?

On scope, the full list is now nine payer numbers; four were in the original
case:

Michael Schubert CZ00000304
Schubert partner a.s. CZ00003118
VEJCE CZ s.r.o. CZ00007040
REALIT INVESTMENT S.R.O. CZ00009677
SCHUBERT PEKÁRNA S.R.O. CZ56892471
AGRO PRODUKCE s.r.o. CZ56892852
JEŘÁBEK & VODRÁŽKA CZ56893979
Realit investment Praha s.r.o. CZ56917687
MSV REAL GROUP s.r.o. CZ56917691

Please confirm all nine sit under the same agreement, and whether any further
payer number is missing from this list.

Technical questions for the test phase:
- Which ColCoCode applies to the Czech Republic? We are using 32; we could
not find a ColCoCode-to-country mapping in the documentation.
- Is AccountNumber mandatory in the searchdocuments and download Filters, or
is ColCoCode + PayerNumber sufficient to return all invoices for a payer?
The published OpenAPI specification marks no field as required or optional.
- If a client is not entitled to a given PayerNumber, does searchdocuments
return an error or an empty result set? We need to distinguish a missing
entitlement from a month with no invoices.

Thank you.

Best regards,
Filip Matěja

In the SIT environment (https://api-test.shell.com), every call to GET /ev/v2/locations returns 401 Unauthorized (E0003: unable to authenticate request) even though the OAuth token is successfully obtained via POST /v2/oauth/token (status 200).

The issue occurs with all tested header variants:
- Bearer token only
- Bearer + client_id / client_secret
- Bearer + apikey
- Bearer + X-IBM-Client-Id / X-IBM-Client-Secret

All variants consistently return:

Code
{
"status": "FAILED",
"errors": [{
"code": "E0003",
"message": "Unauthorized",
"description": "unable to authenticate request"
}]
}

Example request:

Code
GET /ev/v2/locations?evseId=NL*TNM*E01000401*0&country=NED&excludeCountry=NED
Authorization: Bearer <token>
RequestId: 674a4fa7-a0f0-4c23-964e-4c12bdead9a6

Token acquisition works correctly; only subsequent API calls fail authentication.

Please investigate why valid SIT tokens are not accepted by /ev/v2/locations and related endpoints.