Applications & credentials
How your automation platform identifies itself, and how to look after the secret.
What an application is
The identity your automation platform signs in as: a Client ID, a Client Secret, its redirect URLs and the permissions it may ask for. One per platform is the usual shape.
Creating one
- 1
- 2
Name it something the person approving it will recognise — the name appears on the approval screen.
- 3
Choose the automation platform. This selects the request format that platform uses.
- 4
Add the redirect URL it expects. The platform guides list the right value for each one.
- 5
Choose the permissions it needs. Fewer is better; you can add more later, but it needs re-approving.
The client secret
Shown once, and only once
Treat it like a password: keep it in your platform or a secret manager.
Never put it in a browser, a public repository or a workflow's visible fields.
Rotating a secret
A new secret is issued at once; the old one keeps working for a grace period you choose, so live workflows do not break while you update them.
| Grace period | When to use it |
|---|---|
| Immediately | The secret has leaked. Anything still using it breaks now, which is the point. |
| 1 hour | A single workflow you can update straight away. |
| 24 hours | The sensible default — time to update and verify. |
| 7 days | A slow rollout across several platforms or teams. |
Rotation does not sign anyone out — existing tokens keep working.
Redirect URLs
Where we may send the authorization code. Matching is exact — no wildcards, no prefixes.
https://only, excepthttp://localhostfor development.No
#fragment.Add every environment you use; an unlisted URL is refused.
Disabling and deleting
Disable
No new tokens; existing ones run out on their own. Reversible.
Delete
Every credential and authorization revoked. Workflows stop immediately. Not reversible.
Something missing on this page? Tell us and we will fix it.