Registering a self-paid app identity

Status

Current

Updated

2026-09-13

Scope

API Platform app identity onboarding

Choose the right application model first

This page is for a self-paid application identity using client_credentials. If every end user should sign in and authorize your app, with calls charged to that user's own points, use a user-authorized application instead. The two models are not interchangeable and do not share credentials.

When you need one

When you call with an API key, the platform sees you: the call is recorded under your account and points come out of your balance.

If what you are shipping is a long-running application — a scheduled job, a background service, a site you host — tying it to personal credentials causes two problems. The credential follows a person: once that person leaves or revokes the key, the service stops. And the call history mixes into your personal usage, so you cannot tell which calls the application made.

A Consumer App is an identity for the application itself. It exchanges client_credentials for an access token, calls are recorded under the app, and charges go to the app's payer.

If you are just running a script on your own machine or doing a one-off data job, an API key is enough — you do not need this page.

Three steps: apply, review, issue

Go to Console → My Consumer Apps in the API Marketplace.

Step 1: create the application

Three fields:

• App code: lowercase letters, digits, dots or hyphens — for example acme.dashboard. It cannot be changed afterwards; it is the stable identifier for this application.
• Display name: the human-readable name.
• Presentation contract: determines which service versions the app can install. The dropdown only offers contracts the platform currently trusts, and this also cannot be changed after creation.

Once saved the application sits in draft. It has no credentials yet and cannot call anything.

Step 2: submit for review

Submit once the details are correct. The application moves to in review, which is a human review — it never passes automatically.

There are only two outcomes:

• Approved — the application becomes active and you can issue credentials yourself.
• Changes requested — the application returns to draft with a review note explaining what needs to change. Fix it and submit again.

The app code and presentation contract are frozen while the application is under review.

Approval does not mean the platform now holds a credential for you, and it does not turn billing on. Both are your own next steps, below.

Step 3: issue a Client Secret

The credential panel unlocks once the application is active. Enter a reason for the change and click issue Secret.

The plaintext appears exactly once. The page shows the full Client ID and Client Secret; once you navigate away or reload it cannot be retrieved — the platform only stores a one-way hash. Put it into your secret manager or environment variables immediately, and do not commit it to a repository.

From then on you can:

• Rotate: issue a new version. The old Secret stops working immediately. Use this for scheduled rotation or when you suspect exposure.
• Revoke: the application can no longer obtain new access tokens.

Every issue, rotation and revocation is recorded in the app's credential history with your stated reason and a timestamp — but never the Secret itself.

Billing authorization is a separate step

Issuing a credential does not yet let the application spend anything.

Click authorize billing in the billing panel to allow the application to draw points from your Account. Revoke it and the app's calls are rejected outright, with no reservation and no charge.

Keeping credentials and billing separate means "who may call" and "who pays" stay independently controllable: you can issue a credential and verify your wiring first, then turn billing on; or shut off spending without revoking the credential.

Calling with the app identity

Exchange the Client ID and Secret for an access token:

curl -X POST "https://account.zaunekko.com/oauth2/token" \
  -u "zek-app-...:zek_app_..." \
  -d "grant_type=client_credentials"

Tokens are short-lived; just request another when one expires. client_credentials has no refresh token, which is precisely why it suits unattended services: there is no "refresh failed, integration silently died" failure mode.

With a token, manage installations and make calls through the app's own entry point:

curl -X POST "https://api.zaunekko.com/v1/consumer-apps/self/installations/{installationCode}:invoke" \
  -H "Authorization: Bearer {access_token}" \
  -H "Idempotency-Key: your-stable-unique-key"

App calls do not carry parameters in the request body. The request content comes from the installation configuration you saved earlier, and the platform executes the exact service version pinned at that time. A scheduled job therefore runs the same contract every time, with no drift from ad-hoc parameter changes.

Idempotency-Key follows exactly the same rules as personal calls — see Authentication and calls.

Boundaries

• An app identity cannot review, publish, or manage service entities; those require you in a browser.
• You only see applications you created yourself; the console lists no others.
• Revoking a credential or billing authorization does not delete past calls or receipts — history is read-only.