Inbound Auth
Inbound authentication controls how external systems prove their identity when they send webhooks or other OpenLink requests to Soln. Open OpenLink from the Integration menu, select an OpenLink entry, and configure the Inbound Auth tab in the details panel.
Inbound auth belongs to one OpenLink entry, and it is enforced for inbound webhook flows, query flows, and message push flows of that entry.
- Open OpenLink
- Select the target OpenLink entry
- Open the Inbound Auth tab
- Click Configure when no profile exists, or Edit when a profile already exists
- Choose the auth mode
- Fill in or generate the required credentials
- Click Save Inbound Auth
If the mode is changed or no secret is configured yet, the new secret value is required. If the existing secret should remain unchanged, leave the secret field blank while editing.
Auth Modes
| Mode | Required Fields | Notes |
|---|---|---|
| None | None | Accepts inbound requests without an OpenLink-level credential, and deletes the saved inbound auth profile. Use only for trusted testing or when another gateway already authenticates requests |
| Shared Token | Header Name, Token Value | External systems must send the shared token in the configured header |
| Bearer Token | Header Name, Token Value | External systems must send the token in the configured header, with the configured prefix when one is set |
| Signature | App ID, App Secret, Signature Header | External systems must sign requests and send signature-related headers |
Request Header Examples
The examples below show only the headers that inbound authentication expects. The request body is an empty JSON object in every example.
Query flows and message push flows use the same authentication, with their own addresses: /api/open-link/query/<flowCode> and /api/open-link/message-push/<flowCode>.
Inbound requests are checked against the whitelist first, then against the credential profile.
None
POST /api/open-link/inbound/webhooks/<flowCode> HTTP/1.1
Host: <runtime-origin>
Content-Type: application/json
{}
Shared Token
POST /api/open-link/inbound/webhooks/<flowCode> HTTP/1.1
Host: <runtime-origin>
X-OpenLink-Token: <shared-token>
Content-Type: application/json
{}
The header name is the one configured in the shared token profile.
Bearer Token
POST /api/open-link/inbound/webhooks/<flowCode> HTTP/1.1
Host: <runtime-origin>
Authorization: Bearer <token>
Content-Type: application/json
{}
The header name and the prefix come from the profile, and default to Authorization and Bearer. The runtime compares the token after removing the prefix, so a request may also send the bare token.
Signature
POST /api/open-link/inbound/webhooks/<flowCode> HTTP/1.1
Host: <runtime-origin>
X-App-Id: partner-app
X-OpenLink-Timestamp: 2026-09-18T06:30:00.000Z
X-OpenLink-Signature: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
Content-Type: application/json
{}
The signature covers METHOD\npath\ntimestamp\nraw body, and the timestamp must be inside the allowed clock-skew window, so the value in the example is a format reference only. Both signature formats are described below.
Shared Token Fields
| Field | Description |
|---|---|
| Header Name | Header Soln reads from inbound requests, such as X-OpenLink-Token |
| Token Value | Shared secret token. Use the regenerate action when a new token is needed |
Bearer Token Fields
| Field | Description |
|---|---|
| Header Name | Header that carries the token; the default is Authorization |
| Prefix | Optional prefix before the token; the default is Bearer |
| Token Value | Secret token value. Use the regenerate action when a new token is needed |
Signature Fields
| Field | Description |
|---|---|
| App ID | Public application identifier sent in the fixed X-App-Id header |
| App Secret | Secret used to verify the request signature. Use the regenerate action when a new secret is needed |
| Signature Header | Header that carries the signature |
| Timestamp Header | Header that carries the request timestamp |
| Algorithm | HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512; the default is HMAC-SHA256 |
Inbound verification uses the configured algorithm, which defaults to HMAC-SHA256. The caller must sign the exact UTF-8 content below with the configured App Secret:
METHOD\n/path\ntimestamp\nraw JSON body
The method is uppercase. The path excludes the query string. The timestamp must be present in the configured header and may be Unix seconds, Unix milliseconds, or an ISO timestamp. It must be within the configured clock-skew window, which is 300 seconds for profiles created in Runtime Web. The signature header may contain the HMAC as lowercase hexadecimal or Base64.
After verification, Runtime derives an internal replay key from the canonical signature. Repeating the same signed request returns the existing execution and does not start another workflow or repeat business writes. Changing X-Idempotency-Key does not bypass this protection. Keep caller and Runtime clocks synchronized; a fresh timestamp produces a different signed request.