Pro App Secrets

Pro apps often need credentials — an API key, a client id and secret, a token for another system. Secrets let you store those credentials in the managed backend, where the app can use them but never see them.

A secret is write-only: you can set it and replace it, but nobody can read it back — not you, not the App Builder, and not the running app. The interface only ever shows the name and an optional description — no part of the value is ever displayed, not even masked.

When to use secrets

Secrets are never used on their own — they are referenced by a web request, which runs on the backend and attaches the credential there. A secret belongs to the app as a whole; it does not depend on which ERP.net instance you are working with.

Enabling secrets

1. Open the app in the App Builder.
2. Switch to the Backend tab.
3. Select Secrets from the left menu.
4. Turn on the section.

Secrets require a Pro app, and only users with Design access to the app can manage them.

Adding a secret

Click Add secret, then give it:

• a name — starts with a letter, contains letters, digits and underscores, for example ACME_CLIENT_SECRET;
• an optional description — what the credential is for and where it came from;
• the value — stored encrypted immediately and never shown again.

To change a credential later, use Replace and type the new value. There is no way to reveal the old one.

Limits: up to 25 secret names per app, up to 4 KB per value.

A secret is not tied to an ERP.net instance

A secret is simply a name and a value belonging to the app. There is no per-instance variant, and nothing changes when you switch the instance in the top bar.

When a web request needs to talk to a particular ERP.net instance, that instance is fixed inside the request: its address is part of the request's URL and its credentials are the request's own secrets. If the same integration must reach two different instances, define two requests with their own secret names, for example:

CATALOG_DEMO_CLIENT_ID       → used by the request "catalog.demo.products"
CATALOG_DEMO_CLIENT_SECRET

CATALOG_LIVE_CLIENT_ID       → used by the request "catalog.live.products"
CATALOG_LIVE_CLIENT_SECRET

This keeps the behaviour predictable: a request always calls the same destination with the same credentials, no matter who runs the app or what they have selected.

What the App Builder can and cannot do

You can ask the App Builder to prepare the credentials an integration needs:

This app will call the Acme API. Declare the secrets it needs.
Which secrets does this app already have?

When a credential is missing, the App Builder picks a clear name itself (for example ACME_CLIENT_SECRET) and opens the secret form for you, with the name and a short description already filled in. All you do is paste the value and save. If two credentials are needed — an id and a secret — it asks for them one after the other.

The App Builder can see secret names and tell you which ones are still empty, but it can never read or set a value. The value goes straight from your clipboard into encrypted storage.

How secrets stay safe

• Values are encrypted before they are stored and can only be decrypted by the backend while a request runs.
• Nothing in the browser, the app code, or the App Builder conversation ever receives a value.
• Test results and logs redact credentials and authorization headers.