Configure application security and credentials
Retrieve the credentials required by the current Application and optionally restrict OAuth API calls by source IP. User sign-in, application backend calls and HTTPS event receivers use different credentials.
Retrieve current credentials
Open “Application → Credentials and basics” and check the Application, environment, integration status and corresponding Client ID.
| Purpose | Credentials | How to obtain them |
|---|---|---|
| User sign-in | User Client ID; no Client Secret | Enable user identity and register an exact callback in OAuth/OIDC configuration |
| Backend APIs or long connection | Application Client ID and Client Secret | Temporarily reveal or rotate through the credentials page with current permission, or use its approved delivery channel |
| HTTPS events or synchronous callbacks | HMAC Secret; Verification Token and Encrypt Key when configured | Use the dedicated receiver settings in the event page, or its current delivery channel |
Secrets are masked by default. After explicit retrieval, store them in the corresponding server. Leaving the page, changing enterprise or Application, expired sign-in or access changes clears temporary values. Ordinary configuration copies, exports, documentation, logs and tickets contain no Secrets. An Application manager relationship does not automatically grant owner-only credential privileges.
Successful OAuth Client Secret rotation immediately invalidates the old value. Update the server and obtain a new token. Follow Webhook signing-key rotation for receiver credentials; successful delivery does not prove the receiver uses the new value. If verification is requested, complete it and explicitly perform the credential action again.
Restrict source IP addresses
Enable an IP allowlist only when fixed network sources are required. Confirm the actual egress address seen by the platform. Long-connection and ACK requests must also satisfy the policy.
- Open “Application → Security settings”.
- Enable the IP allowlist and enter one allowed IPv4 address, IPv6 address or CIDR per line.
- Save, check the returned set and test requests from both allowed and unallowed networks.
| Configuration | Requirement | Description |
|---|---|---|
| IP allowlist | Optional; disabled when unconfigured | Restricts this Application's application and user OAuth API calls |
| IP addresses or CIDRs | 🔴 Conditionally required when enabled; 1–100 entries | Examples: 203.0.113.10, 203.0.113.0/24, 2001:db8::/32; these are not your actual egress addresses |
Saved addresses are normalized, deduplicated and sorted. Unallowed sources are denied; forged source headers cannot grant access. The policy does not grant API scopes, customer resources or product access.
Recover from a source restriction
The Developer Console remains accessible for policy recovery. A user with current update permission can sign in, change allowed addresses or disable the restriction, save, then verify Application requests again.
| Situation | Action |
|---|---|
| Requests from a new network are denied | Check actual egress, Application and environment, then update the policy |
| Save result is unknown | Retry the original request with its address set, revision and operation identifier |
| Invalid IP address or CIDR | Correct the address identified by the page, then save again |
| Recent identity verification is required | Complete verification from the original page and explicitly save; an unknown request still recovers its original content |
| Revision conflict | Reload the current policy, review it and edit |
| Permissions or configuration cannot be checked | Retry after recovery; temporary failure does not permit access |
| Possible credential exposure | Rotate the corresponding credential; never request the old value in a ticket |
Next: Authentication and authorization · Receive events over a long connection · Support and diagnostics