Postman Collections

Ready-to-use Postman collections for channel partners who want to test TMF onboarding and the SEP (CAMARA) APIs without writing any integration code first. Download the collection for the flow you need, import it into Postman, fill in your own credentials, and run the requests.

The SEP CAMARA API collections below are pre-configured for Germany staging (https://stg.api.telekom.com) as the entered environment. If you want to test against production or a different country, you only need to change the single base_url collection variable — see Endpoints for the full list of staging/production base URLs per country. Every other request in the collection is built from that one variable, so there is nothing else to update. The TMF Onboarding collections work the same way.
The SEP CAMARA API collections all use private key JWT client authentication (private_key_jwt) — never a client secret. After importing one, you only need to fill in three variables before it will work:
  • client_id — your application's client ID
  • private_key — your own PKCS8 PEM RSA private key (replace the placeholder text)
  • kid — optional, only needed if your JWKS contains more than one key
Signing happens entirely inside the collection's Postman scripts using pure JavaScript — no external tools or plugins required. See Authentication & Authorization for background on private key JWT and grant types, and Endpoints for the underlying base URLs, token endpoint, and test phone numbers these collections use as sample data.
For Authorization Code collections, one step must happen outside Postman: opening the authorize URL in a browser, completing consent, and pasting the returned code into the collection's auth_code variable. This is called out in that request's description. CIBA collections poll automatically once you run the backchannel authorize request. Each card below shows which countries currently allow that API/grant-type combination per the product catalog — a collection is still provided even where no country currently allows it, for testing against your own OAuth deployment. The TMF Onboarding collections create a real Application Owner, Application and Product Order against the TMF platform — there is no sandbox/dry-run mode, so only run them with values and a product_offering_id you're actually ready to use.
One Application can only ever be ordered for one version of a given API. Sim Swap v1 and Sim Swap v2 (or KYC Match v0.2 and v0.3) cannot both be ordered onto the same Application — see the Onboarding Guide. If a client_id/ private_key pair was provisioned for one version, using it against the other version's collection will fail with 401 UNAUTHENTICATED (InvalidClaim) even though the credentials are otherwise valid and correctly entered — that's expected, not a bug in the collection. This also applies to the All-in-One collection below: its shared client_id/ private_key only work for the API versions your Application actually ordered — skip the folders for API versions you didn't order, or swap in the matching credentials before running them.
TMF Onboarding (App Owner + Application + Product Order)

Runs the full TMF931 onboarding flow: create an Application Owner, create an Application under that owner, then submit a Product Order for the SEP CAMARA API product you were approved for.

Client Secret
Client Secret

Available in:

🇩🇪
🇵🇱
🇬🇷
🇦🇹
Private Key JWT
Private Key JWT

Available in:

🇩🇪
🇵🇱
🇬🇷
🇦🇹
Sim Swap v1

Detects whether a subscriber's SIM card has been swapped recently.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
🇬🇷
🇦🇹
CIBA
CIBA

Available in:

🇩🇪
🇵🇱
🇬🇷
🇦🇹
Authorization Code
Authorization Code

Not currently listed for any country in the product catalog.

Sim Swap v2

Detects whether a subscriber's SIM card has been swapped recently.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Not currently listed for any country in the product catalog.

KYC Match v0.2

Checks whether subscriber-provided identity/address details match what the operator has on file.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
🇦🇹
CIBA
CIBA

Available in:

🇩🇪
🇦🇹
Authorization Code
Authorization Code

Not currently listed for any country in the product catalog.

KYC Match v0.3

Checks whether subscriber-provided identity/address details match what the operator has on file.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
CIBA
CIBA

Available in:

🇩🇪
🇵🇱
Authorization Code
Authorization Code

Not currently listed for any country in the product catalog.

KYC Age Verification v0.2

Checks whether the subscriber is above a given age threshold, without revealing their exact birthdate.

JWT Bearer
JWT Bearer

Not currently listed for any country in the product catalog.

CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪
KYC Fill-in v0.3

Returns the subscriber's identity/address details already known to the operator, to pre-fill a form. The subscriber is identified via the access token, not a request body field.

JWT Bearer
JWT Bearer

Not currently listed for any country in the product catalog.

CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪
Location Verification v2

Verifies whether the subscriber's device is currently located within a given area.

JWT Bearer
JWT Bearer

Not currently listed for any country in the product catalog.

CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪
Location Retrieval v0.4

Retrieves the subscriber's last known device location.

JWT Bearer
JWT Bearer

Not currently listed for any country in the product catalog.

CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪
Device Roaming Status v1

Checks whether the subscriber's device is currently roaming.

JWT Bearer
JWT Bearer

Not currently listed for any country in the product catalog.

CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪
Device Reachability Status v1

Checks whether the subscriber's device is currently reachable on the network.

JWT Bearer
JWT Bearer

Not currently listed for any country in the product catalog.

CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪
Number Verification v1 (NV1)

Silently verifies that a given phone number matches the device making the request, via a network-based flow while on cellular data.

Authorization Code
Authorization Code

Available in:

🇩🇪
🇵🇱
🇬🇷
🇦🇹
Number Verification v2.1 (NV2)

Verifies a phone number (or looks up the device's phone number) using a TS.43 operator token as the subscriber identifier instead of a phone number.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
🇵🇱
🇬🇷
🇦🇹
Number Recycling v0.2

Checks whether a phone number has been recycled (reassigned to a new subscriber) since a given date.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
CIBA
CIBA

Available in:

🇩🇪
Authorization Code
Authorization Code

Not currently listed for any country in the product catalog.

Quality on Demand v1.1

Creates a temporary network quality-of-service session (e.g. low-latency) for a subscriber's device or a network-based application.

JWT Bearer
JWT Bearer

Available in:

🇩🇪
Authorization Code
Authorization Code

Available in:

🇩🇪

All-in-One (every API and grant type in a single collection)

Every SEP CAMARA API above, combined into a single collection, organized as one folder per API with a sub-folder for every grant type variant built for that API (JWT Bearer, then CIBA, then Authorization Code, in that order, whichever exist) — fill in client_id, private_key and optionally kid once at the top of the collection's Variables tab, and every folder and sub-folder reuses those same shared credentials, so there's nothing to re-enter per API or per grant type. Everything else (scope, phone numbers, and other per-API/per-grant parameters) is namespaced per sub-folder with working defaults already filled in.

All APIs, all grant types
All APIs, all grant types

How to use a collection

Download the collection file for the API and grant type you want to test.

In Postman: File → Import and select the downloaded .postman_collection.json file.

Open the collection's Variables tab and fill in client_id and private_key (and kid if your JWKS has more than one key).

Leave base_url as Germany staging, or change it to production/another country per the Endpoints page.

Run the requests in order, top to bottom. Token requests automatically capture the access token into a collection variable for the requests that follow. For the TMF Onboarding collections, IDs from each step (owner_id, app_id, order_id) are captured automatically too.

For questions contact the MACE team. Client IDs, private keys and offer IDs are shared/generated separately during onboarding — never embedded in these collections.
An unhandled error has occurred. Reload 🗙