Disponible avec la formule « Marketer » et les formules supérieures.
Webhooks are how Pretty Links tells other systems when something happens. Every time a link is added, edited, trashed, restored, or removed, Pretty Links sends an HTTP POST to a URL you specify, with a JSON body describing what happened.
Ce guide fait partie de la Présentation de l'extension « Pretty Links Developer Tools », the entry point for the Developer Tools add-on.
Adding a Subscription
- Aller à Dashboard > Pretty Links > Developer Tools > Webhooks.
- Cliquez sur Add Subscription.
- Fill in:
- URL cible — The full HTTPS URL Pretty Links should POST to. This is usually a webhook URL provided by Zapier, Make, n8n, your custom endpoint, or a Slack/Teams incoming webhook;
- Event types — Which events should trigger this webhook (see below);
- Description — Optional label so you remember what this subscription is for.
- Cliquez sur Économiser.
The subscription is now live. The next time a matching event happens, your target URL will receive a POST.
Event Types
You can subscribe to one event, several events, or all events.
| Event | Fires when |
|---|---|
link-added | A new Pretty Link is created |
link-updated | An existing Pretty Link is edited |
link-trashed | A Pretty Link is moved to trash |
link-restored | A trashed Pretty Link is restored from trash |
link-removed | A Pretty Link is permanently deleted |
tous | All of the above (you’ll receive every link event) |
Pick tous if you want a single subscription to catch everything, or pick specific events if your downstream system only cares about, say, new link creation.
Webhook Security: The PRLI-WEBHOOK-KEY Header
Your site has a single webhook key — shown in Dashboard > Pretty Links > Developer Tools alongside the API key. Pretty Links sends this key in the PRLI-WEBHOOK-KEY header of every POST it sends to a target URL, regardless of which subscription fired.
Your receiving endpoint should check this header. If the value matches the key Pretty Links shows you in the admin, the request is genuine. If it doesn’t match (or is missing), the request is forged and your endpoint should ignore it.
Like the API key, you can regenerate the webhook key from the admin if it’s ever leaked. Regenerating it means updating the comparison value in every receiver you’ve set up.
This is how you protect your endpoint from people sending fake “link added” payloads to your URL. Without the key check, anyone who guesses your webhook URL could trigger your downstream automation.
Most webhook receivers (Zapier, Make, custom code) let you read incoming headers. Compare PRLI-WEBHOOK-KEY to the expected value before processing the payload.
Event Log
Every webhook delivery — successful or not — is recorded in the event log on the Webhooks screen. For each delivery you can see:
- The event type;
- The target URL it was sent to;
- The HTTP response code your endpoint returned;
- The full payload that was sent.
This is valuable for debugging. If a Zap isn’t firing, check the event log: did Pretty Links actually send the webhook? Did your endpoint return a 200, or did it 500? Was the payload what you expected?
Test Send
Next to each subscription is a Test Send action. Click it and Pretty Links sends a sample payload to your target URL right now, without waiting for a real event.
Use Test Send to:
- Verify a new subscription is wired up correctly;
- Confirm the target URL is reachable;
- See what the payload shape looks like in your downstream tool;
- Re-test after changing the target URL.
Common Webhook Setups
Slack alert when a campaign link is created: Subscribe to link-added and point the target URL at a Slack incoming webhook (often via Zapier or Make for formatting).
Auto-archive in spreadsheet when link is trashed: Subscribe to link-trashed and point the target URL at a Zapier webhook that adds a row to a “Deleted Links” Google Sheet.
Sync to a custom CRM: Subscribe to tous and point the target URL at your CRM’s intake endpoint. Use the event type field in the payload to decide what to do on each side.
Retries and Failures
If your endpoint returns a non-2xx response code (or doesn’t respond at all), the delivery is logged as failed. Check your endpoint, fix the issue, then use Test Send to confirm it’s working again. Real events that happened during the outage aren’t automatically replayed, so make sure your endpoint is reliable before depending on webhooks for critical workflows.