API keys & webhooks
Build your own integration against Peleka's public API.
For anything Peleka doesn't connect to natively, its API and outbound webhooks let you build the integration yourself.
API keys
Create one from Settings → API Keys. Each key:
- Is prefixed
pel_...for easy identification in logs. - Is scoped read or write (write is the default; pick read if the integration only needs to look things up).
- Is shown in full exactly once, at creation. Peleka stores only the prefix and a hashed value afterward, so if you lose it, you'll need to roll a new one.
- Can optionally be set to expire after a fixed number of days, for integrations that should re-authenticate periodically rather than run on a key forever.
- Can be rotated from the same screen: this issues a new secret value under the same key (same name, same scope), so you can swap it into your integration and revoke the old value without a gap where nothing works. Revoking outright is also available any time.
What the API covers
The full picture lives in the developer docs, but at a glance: contacts (including CSV import and GDPR-erasure requests), tags, segments, custom fields, broadcasts, forms and their submissions, workspace analytics, and webhooks themselves are all manageable through the API, not just readable.
A read-scoped key gets a clear permissions error on any write-style call. Scope keys to the minimum your integration actually needs.
Webhooks
Manage these from Settings → Webhooks, separately from API keys. Subscribe to outbound events so your other systems hear about activity in Peleka the moment it happens, instead of polling:
| Event | Fires when |
|---|---|
contact.created | A new contact is added, from any source |
contact.updated | Any field on a contact changes |
contact.unsubscribed | A contact unsubscribes |
contact.bounced | A hard bounce is recorded |
contact.complained | A contact marks an email as spam |
contact.tag_added / contact.tag_removed | A tag is added to or removed from a contact |
contact.link_clicked | A link inside a sent email is clicked |
broadcast.sent | A broadcast starts sending |
broadcast.completed | A broadcast finishes sending, successfully or not |
automation.enrolled | A contact enters a journey |
automation.completed | A contact finishes a journey |
form.submitted | A form receives a submission |
Each webhook you create has its own signing secret, used to HMAC-sign every delivery so your endpoint can verify the payload really came from Peleka. Target URLs are validated against SSRF at creation and update time. A failed delivery retries automatically a few times before being marked failed, and a webhook that fails consistently enough gets disabled rather than left silently broken — the delivery log on its settings page shows exactly what was sent and what came back, so you don't need your own logging in place from day one to debug it.
Verify signatures
Always verify the HMAC signature on incoming webhook payloads before trusting them. This is what stops someone else from posting fake events to your endpoint.