Zapier
Make.com
Pabbly Connect
Lovable
Overview
Webhooks let you push article data to any HTTP endpoint the moment TryRoki publishes or updates content. Each account supports up to 3 active webhook endpoints. When an event fires, TryRoki sends a single HTTP POST request with a JSON body to every matching active webhook within seconds. Common uses include syncing articles to a headless CMS, triggering a build pipeline, sending Slack notifications, or logging new content to a spreadsheet.Events
TryRoki fires two webhook events. You can subscribe to one or both when configuring each endpoint.event
Fired when TryRoki finishes generating and publishing a brand-new article. This is the event to use if you want to pipe fresh content into a CMS or trigger a site build on every new post.
event
Fired when an existing article’s content, title, or metadata is changed — for example after a manual edit or an AI-regeneration. Use this to keep downstream systems in sync with the latest version of each article.
Payload
Both events deliver the same JSON body via HTTP POST. TheContent-Type header is always application/json.
Configuring a webhook
Open the TryRoki dashboard and go to Integrations → Webhooks. Click Add webhook and fill in the form:1
Endpoint URL
The full HTTPS URL TryRoki should POST to.
2
Events
Tick On create to receive
article.created, tick On update for article.updated, or enable both.3
Custom headers (optional)
A JSON object of headers to include in every request, useful for authentication tokens.
Custom headers
The headers field accepts a valid JSON object. Each key-value pair is sent as an HTTP request header alongside every webhook delivery. Use this to pass authentication credentials to your endpoint.Delivery behaviour
TryRoki delivers each event asynchronously via a background job. Your endpoint has 15 seconds to respond before the request times out. Any HTTP 2xx status code is treated as a successful delivery. Non-2xx responses and timeouts are logged as failures.Securing your endpoint
Because TryRoki does not sign payloads, the recommended approach is to use a shared secret token via the custom headers field and verify it on every incoming request. For example, set:Authorization header does not match before processing the payload. Additionally, only accept requests over HTTPS to prevent token interception.