Your flows and AI agent tools call your own services through the HTTP node. To protect those calls, store the service's secret as a credential, select that credential in the node, and add a client certificate if the service requires mutual TLS (mTLS).
The examples call a partner accounts service at https://api.example.com/accounts. It expects an API key in an X-API-Key header.
Storing the secret as a credential
A credential stores the authentication for a service once, for the whole tenant. Designers then pick it in the HTTP node, so nobody types the secret into a node. To create one, go to Integrations > Credentials and open New Credential.
1. Credential Name: Required. Designers see this name in the HTTP node's credential list, for example Demo-Partner-API-Key.
2. Description: Optional. Something that helps designers choose the right credential.
3. Authentication Type: Custom Header (the default) sends static header values, such as Authorization or X-Api-Key, with every request. OAuth 2.0 Client Credentials gets an access token from the authorization server and sends it as a Bearer token with every request. You cannot change the type after the credential is created.
4. Header Name: For Custom Header: the header to send, for example X-API-Key.
5. Header Value: For Custom Header: the secret itself.
OAuth 2.0 Client Credentials asks for these fields instead of the header details:
| Field | What to enter |
|---|---|
| Access Token URL | The authorization server's token endpoint. |
| Client ID | The client ID issued by the authorization server. |
| Client Secret | The client secret issued by the authorization server. |
| Scope | The scope to request with the token. |
| Client Authentication | How the client credentials reach the authorization server: Send as Basic Auth header or Send in request body. |
📝 Note: Header Value and Client Secret are encrypted when you save and are never shown again. When you edit a credential, the field is empty and reads "Enter to update current value". Leave it empty to keep the stored value, or type a new value to replace it.
Using the credential in the HTTP node
Open the HTTP node in your flow or AI agent tool.
1. Credential: Between URL and Content Type. Default: None. The list shows the tenant's credentials, each with its type. Select Demo-Partner-API-Key.
2. Headers: Any other headers the service needs. These are sent exactly as you type them.
The node stores only the credential's name. The secret never goes into the flow. At run time, the node adds the credential's header (or the Bearer token it obtained) to the request. If the Headers section has a header with the same name, the credential's header replaces it.
⚠️ Warning: Never put a secret in the Headers section. The execution details of an HTTP call list the headers typed into the node, but never a credential's header. A key typed in as a manual header is therefore visible there.
Adding a client certificate for mTLS
Some services require the caller to present a client certificate. For those, upload the certificate once under Integrations > Certificates, then turn on mTLS in the HTTP node.
1. Certificate Name: Required. Designers see this name in the HTTP node's certificate list, for example Demo-Partner-mTLS.
2. Certificate Format: PFX (the default) or PEM.
3. PFX File: Required. The client certificate file.
4. Password: Optional. The PFX file's password, if it has one.
5. CA Certificate: Optional.
6. Common Name, Issuer, Valid From, Valid Until: Read from the file after upload. You cannot edit them.
If you choose PEM, the form asks for Certificate File, Private Key File and an optional CA Certificate. A certificate (or intermediate certificate) that has expired or is not yet valid is refused when you save. In the certificate list, an expired certificate shows an Expired badge.
💡 Tip: To renew a certificate, open the existing one and upload the new file to it. Do not create a new certificate. HTTP nodes refer to the certificate itself, not to its name, so every node that uses it keeps working without changes. Renaming a certificate does not break them either.
Next, turn on mTLS in the HTTP node. Click the gear icon to open its advanced settings.
1. Enable mTLS: Off by default. Switch it on.
2. Client Certificate: Required once mTLS is on. The list shows the tenant's certificates. Select Demo-Partner-mTLS.
The node now presents this certificate when it calls the service. The service can then refuse any caller that does not present it.
What stays protected
| Item | How it is protected |
|---|---|
| Header Value and Client Secret | Encrypted when saved. Never shown again or returned by the API. The credential list shows the header name with a masked value. |
| Private key, PFX content and password | Encrypted when saved and never shown again. The certificate page shows only Common Name, Issuer and the validity dates. |
| Execution details | List only the headers typed into the node. A credential's header never appears. For an mTLS call, they show only that mTLS was used and the certificate's name. |
| Project exports | Contain no credential or integration secrets. A project file holds only the names of the integrations it uses. |
Who can manage credentials and certificates
Both sets of permissions are in the Designer permission group.
| Permission | What it allows |
|---|---|
| Credentials | Viewing the credentials under Integrations > Credentials. |
| Credentials > Edit | Creating and changing credentials. |
| Certificates | Viewing the certificates under Integrations > Certificates. |
| Certificates > Edit | Uploading and changing certificates. |
To give these permissions to users through roles, see Multi-Tenant Management & Role-Based Access Control (RBAC).
Limits and naming rules
| Item | Rule |
|---|---|
| Credential Name | Letters, numbers, underscores and hyphens only. No spaces. Up to 200 characters. |
| PFX File | .pfx or .p12, up to 5 MB. |
| CA Certificate | .pem or .crt, up to 5 MB. |
| Authentication Type | Fixed once the credential is created. |