Skip to navigation

Security & keys

The secret your backend signs in with, and the optional key pair for sending us sensitive values encrypted
View as Markdown

App Settings → Security & Keys holds two very different things, and it helps to keep them apart from the first minute:

App secrets — who is calling

The Application ID says which application is calling. A secret proves it. Every request to our APIs carries one.

Encryption keys — what you send

Optional. A public key you can use to encrypt sensitive values before they leave your servers, so only we can read them on arrival.


App secrets

The API Secrets card in the Console: the Application ID row, one live secret with its Revoke action, one revoked secret struck through, and the Create new secret button highlighted The API Secrets card in the Console: the Application ID row, one live secret with its Revoke action, one revoked secret struck through, and the Create new secret button highlighted

The card lists the Application ID — the line support will ask you for, with a copy button — and every secret the application has held, live or revoked. You will notice the secrets themselves are not there: a secret is shown once, at creation, and never again. What the card keeps is a short identifier, so you can tell them apart when you revoke one.

1

Create one

Create new secret opens a sheet that explains what the secret grants, generates it and shows it. Copy it there and then; closing the sheet is the last time anyone sees it.

2

Put it on your server, and nowhere else

It travels in the X-APP-SECRET header of every API call (how the header works). It can start executions for any of your customers and read everything extracted under the application — so it never goes into a browser, a mobile app or a front-end bundle.

3

Rotate without a gap

Up to five secrets live at once. Mint the new one, deploy it, then revoke the old one: at no point is the application without a working secret. Revoking never touches the application, its executions or its data.

Lost a secret, or think one leaked? Revoke it here. The call fails for whoever holds it from that second, with the code app_secret_revoked, and nothing else about the application changes. Then create a new one.


Encryption keys

Everything you send us already travels over TLS. The key pair is for the values you want protected even inside the request body — a customer’s bank password, a document number — so that not even an intercepted or logged body reveals them. It is optional, and you choose field by field.

The Inbound encryption keys card before a pair exists: the explanation of what the pair is for, the note that the application has no key pair yet, and the Generate the key pair button highlighted The Inbound encryption keys card before a pair exists: the explanation of what the pair is for, the note that the application has no key pair yet, and the Generate the key pair button highlighted
1

Generate the pair — once

One press, no form. It mints an RSA pair: the public half appears in the card, the private half stays with INFONITE, stored encrypted and served by nothing — not to this screen, not to anyone. It is not a rotation: once a pair exists, it stays.

2

Install the public key on your side

Copy the PEM, download it, or read the fingerprint aloud to confirm you both hold the same key. It has no expiry date.

The Inbound encryption keys card with a pair generated: the Public key (PEM) block highlighted, with its fingerprint and download action, and the X.509 certificate block below with its validity dates and the Renew certificate actionThe Inbound encryption keys card with a pair generated: the Public key (PEM) block highlighted, with its fingerprint and download action, and the X.509 certificate block below with its validity dates and the Renew certificate action
3

Encrypt the fields you choose

A value encrypted with the public key is sent with a small prefix that says how: rsa:: for one short value, hybrid:: for anything longer. We decrypt on arrival with the private half. The exact envelopes, with code, are in the encryption guide.

Some tooling expects a certificate rather than a bare key. The X.509 certificate in the card wraps the same public key for that tooling — it is the only part with dates. When it nears expiry, Renew certificate issues a new one over the same key: nothing you already encrypted is affected, and nothing on your side needs re-keying.

Everyone with a seat can read this screen — it only ever shows public material. Creating and revoking secrets, and generating the pair, need the organization manager role, and are read-only while the application is locked.