Webhook keys
Webhook keys help your receiving tool verify that a webhook delivery came from Atomicat. The API key modal is available from webhook management screens and can fetch, generate, copy, or regenerate the current key.
Treat every key as a secret. Do not paste it into screenshots, Loom videos, chat logs, public docs, browser snippets, or client-side page code.
Open the modal​
- Go to Form webhook delivery or Quiz webhook delivery.
- Click API key management in the header.
The modal follows the webhook area you opened. Form and quiz webhook flows can use their own API hooks, so do not assume one copied key covers every destination without checking the relevant modal.
Read the guidance​
The product explains that your receiving tool should use the key to validate webhook deliveries. A note below the key reminds you to keep the key private and rotate it if exposure is suspected.
Generate or rotate​
- If no key exists yet, the primary button reads Generate API key.
- After a key exists, the same button becomes Regenerate API key.
- A loading state shows Generating while Atomicat creates or rotates the key.
- Regenerating changes the secret your receiver must accept.
Copy the key​
When a key is present, it appears in a read-only field with a Copy action. After copying, the button briefly shows a check/copied state so you know the clipboard write succeeded.
Paste the key into your server, automation platform, middleware, or secret manager. Do not paste it into Atomicat page custom code; webhook verification belongs on the receiving side.
Rotate safely​
- Open the receiving service and prepare it to accept the new key.
- Generate or regenerate the key in Atomicat.
- Copy the new value immediately.
- Update the receiver.
- Send a test form or quiz submission.
- Check webhook history for success or failure.
Rotate during a low-traffic period if webhooks are business-critical.
Operational practices​
| Practice | Why it matters |
|---|---|
| Rotate on schedule | Limits blast radius if a key leaks. |
| Different keys per environment | Production and testing destinations should not share secrets. |
| Verify before processing | Reject requests that do not include the expected key. |
| Limit access | Only trusted operators should view or regenerate webhook keys. |
| Check delivery logs | Webhook history shows success, failure, payload, response, and resend actions. |
If your setup is custom, ask your technical team which header or validation rule your receiving tool expects.
Troubleshooting​
- If the receiver rejects all webhooks after rotation, confirm the new key was saved on the receiver.
- If copying fails, select the read-only field value manually and copy it.
- If deliveries still fail, inspect webhook history, payload, response, status, and retry count.
- If a key was exposed, regenerate it and remove the old value from every integration.
Related docs​
Frequently asked questions​
Will old deliveries break immediately after regeneration?
Any inflight retries may still use the old secret until they finish. Plan rotations during low traffic windows and update your server before or in sync with the UI action.
Is the webhook key the same thing as my user login?
No. Your login identifies you as a person using Atomicat. Webhook keys help external systems verify automated webhook deliveries.
Where should I validate the key?
Validate it on the receiving server or automation tool before accepting the payload. Client-side page code is not a safe place to store webhook secrets.
Can I resend a failed webhook after fixing the key?
Webhook management includes resend actions for delivery history. Fix the receiver first, then resend the failed delivery when available.