---
name: Onboard an API invoker with ETSI OpenCAPIF
description: >-
Onboard, update and offboard an API invoker against ETSI OpenCAPIF — the ETSI SDG
implementation of the 3GPP Common API Framework (TS 29.222) — and read the access control
policy and invocation audit log that govern it.
api: openapi/capif/capif-api-invoker-management.yaml, openapi/capif/capif-api-provider-management.yaml,
openapi/capif/capif-access-control-policy.yaml, openapi/capif/capif-auditing.yaml
operations:
- create_onboarded_api_invoker
- update_ind_onboarded_api_invoker
- modify_ind_api_invoke_enrolment
- delete_ind_onboarded_api_invoker
generated: '2026-07-25'
method: generated
source: openapi/capif/ (3GPP TS 29.222 as implemented by ETSI SDG OpenCAPIF)
---
# Onboard an API invoker with ETSI OpenCAPIF
CAPIF is 3GPP's Common API Framework — the northbound gate a mobile operator puts in front of its
network APIs. ETSI's OpenCAPIF Software Development Group ships the reference implementation.
This skill covers the invoker side: getting your application admitted so it can call operator APIs.
## Before you start
- Docs: — code:
- There is a **first-party Python SDK**: `pip install opencapif-sdk`
(, source at ).
Prefer it over hand-rolling the certificate and token dance.
- Authorization is **OAuth 2.0 client credentials**. The token URL is a deployment template
(`{tokenUrl}`) — the CAPIF core function tells you the real one during onboarding.
- Errors are RFC 7807/9457 `ProblemDetails` on `application/problem+json`.
- Base path: `{apiRoot}/api-invoker-management/v1`.
## Steps
1. **Onboard.** `create_onboarded_api_invoker` — `POST /onboardedInvokers` with an
`APIInvokerEnrolmentDetails` body: your `notificationDestination`, the
`onboardingInformation.apiInvokerPublicKey` (the CAPIF core signs it and returns your invoker
certificate), and `apiList` if you already know which service APIs you want. The response
carries your `apiInvokerId` and the signed certificate — **this is the credential everything
else depends on.**
2. **Keep it current.** `update_ind_onboarded_api_invoker` —
`PUT /onboardedInvokers/{onboardingId}` for a full replacement of the enrolment, or
`modify_ind_api_invoke_enrolment` — `PATCH /onboardedInvokers/{onboardingId}` for a partial
change (adding an API to `apiList`, rotating the notification destination).
3. **Check what you are allowed to call.** The Access Control Policy API
(`openapi/capif/capif-access-control-policy.yaml`) returns the per-invoker, per-service policy
the CAPIF core will enforce — including any rate limits and time-window restrictions. Read it
before you assume an operation will succeed.
4. **Audit your own invocations.** The CAPIF Auditing API
(`openapi/capif/capif-auditing.yaml`) exposes the invocation log. Use it to reconcile what you
think you called with what the operator recorded.
5. **Offboard.** `delete_ind_onboarded_api_invoker` —
`DELETE /onboardedInvokers/{onboardingId}`. This revokes the invoker certificate. Do it when
you decommission the application rather than leaving a live credential behind.
## Notes
- The **provider** side is symmetric: `openapi/capif/capif-api-provider-management.yaml` is what
an API exposing function uses to register itself with the same CAPIF core. Onboarding an
invoker and registering a provider are two halves of the same framework.
- No idempotency key. `create_onboarded_api_invoker` on an invoker you already onboarded creates
a second enrolment — check first, do not blind-retry.
## Failure modes
| Status | Meaning |
|---|---|
| 400 | malformed enrolment body, or an unusable public key |
| 401 | missing or expired client-credentials token |
| 403 | the CAPIF core's access control policy forbids this |
| 404 | unknown `onboardingId` — you may already be offboarded |
| 411 / 413 / 414 / 415 | CAPIF is strict about Content-Length, body size, URI length and media type |
| 429 | rate limited by the CAPIF core |