Credentials and keys

This page explains the two credentials Monaiq gives you, where each comes from, and what happens when you revoke or rotate.

The two formats

The API key is the secret that authenticates your whole account to the Monaiq APIs. It is your server-side identity: the embedded checkout calls, the management API and the instance surfaces take it. Under Monaiq’s flat tenancy it is also the key your account sells with, so it belongs on a server you control and nowhere else. It never ships inside an application you distribute, and it is never part of an encoded credential.

The encoded credential is a single portable string that starts SIDUB_LIC_. It bundles the seat id, the service key id, the service key public member and a runtime token minted for that one seat into one value, so you configure one setting instead of four. Both SDKs take it directly, and it is the format the quickstarts use. The seat page calls it a license code.

The two are not interchangeable, and that is the point. An encoded credential authorizes and meters the one seat it names, and can do nothing else — which is what makes it safe to hand to a buyer and to install in an application you distribute. An API key is the account.

The Node client also accepts the parts individually — seatId, serviceKeyId, serviceKeyPublicMember and runtimeToken — for cases where your configuration already holds them separately. They are the same four values the encoded string carries.

Caution

Both are secrets. SIDUB_LIC_ is transport encoding, not encryption: anyone holding the string can decode it and read the token inside. Keep either in a secret store or protected configuration, never in source control and never in a log.

What is inside an encoded credential

The payload carries Version, SeatId, ServiceKeyId, ServiceKeyPublicMember and RuntimeToken, and Version is 2. Decoders accept version 2 only — an older payload named the seat LicenseId and is refused, not reinterpreted. The runtime token is opaque to your application: it is a signed token the gateway validates. Never decode it, never parse it, never log or display it — pass it through as received.

The token has no expiry of its own. It lives as long as the seat it names, or until the credential is revoked (MON-374).

Where to get them

An encoded credential comes from the seat it belongs to. Open the seat at monaiq.com/manage/licenses/{licenseId}/seats/{seatId}, and under Credentials name the machine or app in the optional Label field and press Issue license code. The value is shown once, at issue, and never again — copy it then. If you lose one, issue another and revoke the old one.

A purchase hands one back directly: a completed checkout result carries it as EncodedCredential, which is the value your application stores. See In-app purchase and Deliver to your customers.

The API key is at monaiq.com/manage/credentials. The page shows “Your API key”, and mints one for you the first time you visit, so there is no separate create step. That page is the key’s only home: the license page does not show it and does not rotate it.

If you work through an assistant, the profile tool retrieves your account credentials as well. See AI-assisted setup.

Caution

Credentials are only ever shown inside your signed-in account. Monaiq never sends a key or a license code by email. Our emails link to the portal; they never contain the value itself, so treat any message that does contain one as suspect.

Putting one into a project

Read the value from configuration rather than writing it into a file that is checked in.

• .NET. Set LicensingServiceOptions.EncodedCredential from a configuration key. The .NET quickstart reads it from Licensing:EncodedCredential, so you can supply the real value from user secrets while you develop and from the host’s configuration in production without the code changing.
• Node. Pass encodedCredential from the environment. The Node and React quickstart reads MONAIQ_CREDENTIAL.

There is nothing else to set. The SDK decodes the string, calls the runtime operations under {licenseServiceUri}/runtime and {consumptionServiceUri}/runtime, and presents the token as Authorization: Bearer for you.

If you would rather not do the plumbing yourself, the provision_api_key_config tool returns the exact commands and file edits for your project.

Issuing, listing and revoking

Issue as many credentials per seat as you need — one per machine, per deployment or per environment — and label each one so a list of several is one you can act on. The seat page lists what exists: the short form of each code, its label, when it was issued, and whether it is live or revoked. A revoked row stays on the list, because removing it would leave you unable to tell “revoked” from “never issued”.

Revoke is per credential. The rest of the seat, and every other credential issued against it, keep working.

Doing it from your own backend

Everything the seat page does, the management API does too, for any seat your account issued. POST /licensing-mgmt/licenses/{licenseId}/seats/{seatId}/credentials issues one and returns the encoded credential, GET on the same path lists what the seat has, and DELETE /licensing-mgmt/licenses/{licenseId}/seats/{seatId}/credentials/{credentialId} revokes one. The calls take the account API key in dub-apiKey.

This is how you hand a credential to a customer at the moment they need one, rather than asking them to open the portal: provision the machine, issue a credential for it, install the value, and revoke it when the machine goes away. The Label you send is what tells the two apart later.

The same rule applies as on the seat page, and the API cannot soften it: the encoded credential comes back once, in the response to the issue that minted it. Store it then. A listing never returns it, and nothing can read it back. The wire contract is in the HTTP API reference.

What revoking does, and when

Revoking a credential takes effect at the application’s next authorization refresh. An authorization already issued stays valid until its next refresh, bounded by the configured authorization duration (7 days by default) plus the 60-minute stale grace.

Metered usage is different: consumption reported under a revoked credential is dropped when it is ingested, not billed.

Rotating the API key

Rotate from the Credentials page in the portal, or with the rotate_api_key tool from an assistant or any MCP client.

Caution

The old key stops authenticating immediately. There is no overlap window and no grace period, so anything still holding the old value starts failing the moment you rotate.

Because of that, rotate deliberately:

1. Know which deployments, environments and machines hold the current value.
2. Rotate.
3. Update every one of them with the new value.

For a single application that reads from one secret store this is quick. For several environments, plan the order before you press the button rather than after.

Rotate when a key may have been exposed, when someone who had access to it leaves, or on whatever schedule your own policy sets.

Rotating the API key does not touch any encoded credential. The two are separate authorities, so a rotation does not invalidate what your buyers have installed.

The buyer is the credential

When an application you distribute sells your offerings from inside itself, it ships with neither of the formats above. The buyer signs in with their Monaiq identity and the purchase is made with the buyer’s own token, so no seller key ships in the build — there is nothing in the binary to extract. The app reads your catalog anonymously and presents the buyer’s bearer only on the two checkout calls. In-app purchase covers the sign-in options and the client.

What the buyer receives at the end of that purchase is an encoded credential of their own, and it carries a runtime token for the seat they just bought — not a key of theirs and not a key of yours. It authorizes and meters that one seat, it can be revoked from the seat page on its own, and it reaches nothing else on the platform. Treat it as the secret it is, in the platform’s secure store rather than a log or a plain file, but a leak costs the buyer one revocable seat rather than their account.

If you bought a product rather than built one

Credentials for something you bought are on the seat’s detail page in your account, alongside its features (the license’s, the same on every seat) and your usage against them; the license carries the billing. See Your licenses.