Outbound Auth
Outbound authentication provides the credentials Soln uses when calling an external API. Open OpenLink from the Integration menu, select an OpenLink entry, and configure the Outbound Auth tab in the details panel.
Outbound auth belongs to one OpenLink entry, and the saved profile is applied to every outbound call under that entry.
- Open OpenLink
- Select the target OpenLink entry
- Open the Outbound Auth tab
- Click Configure when no profile exists, or Edit when a profile already exists
- Choose the auth type
- Fill in the required fields
- Click Save Config
When an existing secret is already configured, secret fields can be left blank if you do not want to replace the secret. Enter a new secret value only when the credential should be updated.
When Outbound Auth Applies
Outbound auth is read at execution time, so saving the profile applies to the next execution and does not require republishing the flow.
| Execution | Behavior |
|---|---|
| Outbound flow | The Studio script carries the credential, and every studio.http.request call the script makes is signed with it |
| Inbound flow with the Poll trigger | The Studio source script carries the credential when it reads from the external system |
| Other executions, such as webhook inbound, query, and message push flows | No outbound credential is added, because these executions do not run the Studio HTTP runtime |
| Verify connection on the auth tab | Verifies the saved profile with the same rules |
Which profile is used:
- The auth profile bound to the flow binding, when a binding specifies one
- Otherwise the default profile of that OpenLink entry, which must be active
The credential is applied to each outbound request after the script's own headers, so it replaces a header with the same name. When no active default profile exists, outbound calls run without the credential; when a flow binds an inactive profile or a profile of another OpenLink entry, the execution fails.
Auth Types
| Auth Type | Required Fields | Notes |
|---|---|---|
| None | None | Use when the external system does not require OpenLink-level authentication |
| Basic Auth | Username, Password | Sends a username and password credential |
| Bearer Token | Header Name, Token | The header usually uses Authorization; the prefix is commonly Bearer |
| Dynamic JWT Bearer | Algorithm, Secret, Issuer, Audience, Subject, Token lifetime, Header name | Generates a new signed JWT immediately before each outbound HTTP request; the algorithm can be HS256, HS384, or HS512 |
| API Key | Location, API Key Name, API Key Value | The key can be sent in a header or query parameter |
| HMAC Signature | App ID, App Secret, Signature Header, Algorithm | Signs requests with HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512; timestamp, nonce, and sign content rule fields are optional |
| OAuth2 Client Credentials | Client ID, Client Secret, Token URL | Requests an access token with grant_type=client_credentials and HTTP Basic client authentication; Scope and Audience are optional token request parameters |
| Custom Header / Query | Credential JSON, Secret JSON | Maps raw headers or query parameters, referencing secrets from the secret JSON |
Each OpenLink entry keeps one default outbound auth profile. Saving the profile applies the credential to every outbound call under that entry, and choosing None keeps the profile without adding authentication headers.
Request Header Examples
The examples below show only the headers that OpenLink outbound authentication adds. The request body is an empty JSON object in every example.
None
POST /api/orders HTTP/1.1
Host: api.partner.example
Content-Type: application/json
{}
Basic Auth
POST /api/orders HTTP/1.1
Host: api.partner.example
Authorization: Basic ZGVtby11c2VyOmRlbW8tcGFzc3dvcmQ=
Content-Type: application/json
{}
The value is Basic followed by the Base64 of username:password.
Bearer Token
POST /api/orders HTTP/1.1
Host: api.partner.example
Authorization: Bearer <token>
Content-Type: application/json
{}
The header name and the prefix come from the profile, and default to Authorization and Bearer.
Dynamic JWT Bearer
POST /api/orders HTTP/1.1
Host: api.partner.example
Authorization: Bearer <JWT signed for this request>
Content-Type: application/json
{}
Runtime signs the token immediately before the request, so iss, aud, sub, iat, exp, and jti are always present.
API Key
POST /api/orders HTTP/1.1
Host: api.partner.example
X-API-Key: <api-key>
Content-Type: application/json
{}
POST /api/orders?api_key=<api-key> HTTP/1.1
Host: api.partner.example
Content-Type: application/json
{}
The header or parameter name comes from the profile, and defaults to X-API-Key for the header location and api_key for the query location. A configured prefix is inserted before the key value. When the key is sent as a query parameter, Runtime masks its value as [REDACTED] in the execution output.
HMAC Signature
POST /api/orders HTTP/1.1
Host: api.partner.example
X-App-Id: partner-app
X-OpenLink-Timestamp: 2026-09-18T06:30:00.000Z
X-OpenLink-Signature: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
X-OpenLink-Nonce: 3f1c2f0e-6a1d-4a1f-9a53-1f2b3c4d5e6f
Content-Type: application/json
{}
The signature is the lowercase hex digest of the signing content built from the configured rule, which defaults to method + path + timestamp + body. A nonce header is added only when one is configured, and new profiles pre-fill X-OpenLink-Nonce in the console. The nonce is part of the signature only when the rule includes nonce.
OAuth2 Client Credentials
POST /api/orders HTTP/1.1
Host: api.partner.example
Authorization: Bearer <access token from the token endpoint>
Content-Type: application/json
{}
Custom Header / Query
POST /api/orders?tenant=demo HTTP/1.1
Host: api.partner.example
X-Client-Id: demo-client
X-Client-Secret: <secret>
Content-Type: application/json
{}
Only the entries defined in the credential JSON and the secret JSON are added.
Bearer Token Fields
| Field | Description |
|---|---|
| Header Name | Request header that carries the token |
| Prefix | Optional token prefix, such as Bearer |
| Access Token | Secret token value |
Dynamic JWT Bearer Fields
Dynamic JWT Bearer does not call a token endpoint. Runtime signs a new token immediately before each Studio outbound HTTP request and injects it into the configured header, so the Studio script does not need to build the JWT, and Runtime replaces the header if the script sets the same one.
| Field | Required | Description |
|---|---|---|
| Algorithm | Yes | HS256, HS384, or HS512 |
| Secret | Yes when created | Shared signing secret. The minimum length depends on the algorithm: 32 bytes for HS256, 48 for HS384, 64 for HS512. Leave it blank while editing to retain the current secret |
| Issuer | Yes | Value written to the iss claim. It must match the issuer accepted by the external API |
| Audience | Yes | Value written to the aud claim. It must match the target API audience |
| Subject | Yes | Integration operator identity written to the sub claim |
| Name | No | Optional name claim |
| Scope | No | Optional scope claim |
| Token Lifetime | Yes | Integer from 30 to 3,600 seconds |
| Header Name | Yes | Header receiving the signed token. The default is Authorization |
| Prefix | No | Prefix inserted before the token. The default is Bearer |
Each generated token contains iss, aud, sub, iat, exp, and a unique jti. name and scope are included when configured. Tokens are not cached. The secret stays on the server: the interface returns only whether a secret is configured and the names of the secret keys.
API Key Fields
| Field | Description |
|---|---|
| Attach To | Choose whether the key is sent in a header or query parameter |
| API Key Name | Header name or query parameter name |
| API Key Value | Secret key value |
| Prefix | Optional prefix added before the key value |
HMAC Signature Fields
| Field | Description |
|---|---|
| App ID | Public application identifier |
| App Secret | Secret used for signing |
| Signature Header | Header that carries the generated signature |
| Algorithm | HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 |
| Timestamp Header | Header that carries the request timestamp; the default is X-OpenLink-Timestamp |
| Nonce Header | Optional header used to prevent replay |
| Sign Content Rule | Description of the content that should be signed, such as method, path, timestamp, and body |
OAuth2 Client Credentials Fields
| Field | Description |
|---|---|
| Client ID | Client identifier registered at the external system |
| Client Secret | Secret of that client. Leave it blank while editing to retain the current secret |
| Token URL | Endpoint that issues the access token |
| Scope | Optional scope sent to the token endpoint |
| Audience | Optional audience sent to the token endpoint |
Custom Header / Query Fields
| Field | Description |
|---|---|
| Credential JSON | Defines the outbound mapping with headers, query, secretHeaders, or secretQuery; at least one of them is required |
| Secret JSON | Provides the secret values referenced by the credential JSON. Every referenced secret key must exist in this object |
Verify An Outbound Connection
Use Verify connection on the outbound auth tab to check that the saved credentials actually work before relying on them.
- Open the Outbound Auth tab of the OpenLink entry
- Choose Verify connection
- Enter the verification request: URL, method, optional body, and content type
- Choose Start verification and read the result
| Verification field | Description |
|---|---|
| Verification URL | Valid HTTPS address without embedded credentials |
| Request method | GET, POST, PUT, PATCH, DELETE, or HEAD; the default is GET |
| Request body | Optional; GET and HEAD requests cannot carry a body |
| Content type | Content type sent with the probe request |
The summary card shows the verification status and the last verified time:
| Status | Meaning |
|---|---|
| Unverified | The profile has not been verified yet |
| Valid | The probe succeeded with the configured credentials |
| Invalid | The external system rejected the credentials |
| Expired | The auth profile has expired and must be renewed |
| Error | The probe failed for another reason, such as an unreachable endpoint, a rate limit, or another error status |
The result also reports the HTTP status code and the duration in milliseconds.