Releaseo integrations

Integrations Route selected product events to the tools your team uses.

Live routing

Directory Destinations

PostHog Product analytics stream

Enabled

Webhook Out Signed event destinations

2 destinations

GitHub Issues, releases, and roadmap

Connected

Slack Channel broadcasts and events

Connected

Discord Community broadcasts and events

Connected

Webhook Out Signed destinations

Production Sales automation Zapier Catch Hook

4 events Healthy

Production Support handoff Custom receiver

2 events Ready

Last delivery Success 35 seconds ago

Event routing Selected signals

Widget openedContact CTAContact submittedCustom event

Contact-ready Submissions can trigger inbox review and outbound routing.

Contact and widget events GitHub, Slack, Discord, PostHog, and Webhook Out Delivery logs

Available destinations

Destination	Use it when
GitHub	You want customer requests and roadmap work connected to GitHub issues, with one controlled release direction per repository.
Slack	Your team needs changelog broadcasts and selected event notifications in connected Slack channels.
Discord	Your community or team needs changelog broadcasts and selected event notifications in a connected Discord channel.
PostHog	You want Releaseo widget and selected custom events in your product analytics project.
Webhook Out	You want signed event delivery to your own backend, Zapier, Make, n8n, or another HTTPS workflow endpoint.

GitHub, Slack, Discord, PostHog, and Webhook Out are available now. Zapier, Make, n8n, or an internal service connect through a Webhook Out destination; they do not need a separate Releaseo OAuth connection.

GitHub

GitHub carries engineering work through Releaseo’s customer communication loop:

Customer request → GitHub delivery → Ready to announce → publish once → notify requesters.

Connect a repository

1. Open Dashboard -> Integrations -> GitHub and select Install the GitHub App.
2. On GitHub, choose Only select repositories and grant access only to the repositories you want Releaseo to connect.
3. Back in Releaseo, choose a repository and one release direction.
4. Review its automation settings, then use Test before relying on the workflow.

Releaseo uses the GitHub App installation; you do not copy a personal access token into your site or expose GitHub credentials to the Releaseo SDK.

Choose one release direction

Each connected repository has exactly one release direction. Issue linking and status updates work in either mode.

Mode	What happens
Releaseo writes the announcement	Add a release version to a changelog post. Publishing can create a draft GitHub release with the post content as its release notes. GitHub does not publish the release automatically.
GitHub is where releases happen	Publishing a GitHub release creates a draft Releaseo changelog post from the release notes, ready for your team to review and publish.

Keeping one direction per repository prevents a GitHub release and a Releaseo post from overwriting each other.

Link issues to customer work

Open a feature request or roadmap item and use its GitHub section to either:

• open a new issue in a connected repository
• adopt an existing issue by number
• follow the issue’s open or closed state from Releaseo
• detach the link without deleting the issue on GitHub

Automation can also open an issue when a request is approved or when a roadmap item enters a selected column. A connected repository may import labelled GitHub issues into an internal-only roadmap column.

When GitHub reports a linked issue as completed, Releaseo stages the related work for announcement. A Closed — not planned issue is not treated as shipped. The customer loop closes only when your team publishes the changelog; requester emails also require the repository notification option and a working workspace SMTP configuration.

Event notification setup

Use this path when a product event should send a useful, channel-ready message:

1. In Dashboard -> Integrations, connect a Slack workspace or Discord channel and create or enable the destination that should receive messages.
2. In Dashboard -> Events, create an active custom event trigger and declare the payload fields your application will send.
3. Open that trigger’s Notifications action, choose one or more Slack or Discord destinations, and write the message to send.
4. Call window.releaseo.track() with the same event key from your host app.
5. Use the destination’s test action and delivery logs before relying on it in production.

The host app never needs a Slack webhook URL, Discord credential, delivery secret, or channel identifier.

Slack

Connect a Slack workspace from Dashboard -> Integrations -> Slack, then select the channels to use as destinations. Each destination is an individual Slack channel, so you can route engineering alerts and customer-success alerts separately.

Enable Publish changelog posts to this channel to make the channel eligible for release broadcasts. When editing a changelog post, use Share to Slack to select the connected channels that receive that post on publication.

For event notifications, choose the Slack channels from the event’s Notifications dialog. Releaseo groups events that arrive close together and uses a per-channel delivery budget, so bursts become a summary instead of flooding a channel. Destination delivery logs show the resulting messages and any failures.

Discord

Connect Discord from Dashboard -> Integrations -> Discord and authorize the channel that should receive Releaseo messages. A Discord destination can:

• send selected events in realtime
• include identity payloads when you explicitly enable them
• filter delivery by all, identified, anonymous, selected user IDs, or selected email addresses
• send scheduled summaries using the same event selection and audience filter
• receive changelog posts when Receive changelog posts is enabled

Use the changelog post’s Share to Discord section to choose the enabled Discord destinations for that post. Use an event’s Notifications dialog to choose which custom event notifications go to Discord.

Event notifications and custom messages

An event notification links one active trigger to one or more Slack and Discord destinations. The same notification configuration is saved across every selected destination, so the message is consistent wherever the event is sent.

Start by defining a stable, lowercase event key and its expected payload fields in Dashboard -> Events. For example, define trial_started with plan and workspace_name fields, then emit it from your application:

await window.releaseo.track("trial_started", {
  plan: "team",
  workspace_name: "Acme",
});

In the trigger’s Notifications dialog you can:

• select Slack channels and Discord destinations
• keep or remove the trigger title and description
• write a custom message and type { in the editor to insert a field
• insert declared event fields, approved user properties, or trigger metadata
• preview the output with real-looking or missing values before saving

The editor stores structured fields rather than a hand-written placeholder syntax. If a value is absent, its fallback text is shown. Releaseo validates that event fields were declared on the trigger, blocks secret-like field names, and respects the destination’s property-sharing settings. A default message uses the trigger title and description when you reset the custom message.

Custom event definitions are also used by event-triggered In-app Launches. One track() call can therefore show a matching banner, toast, or modal and send a selected Slack or Discord notification; each feature still follows its own targeting and frequency rules.

Event catalog

The dashboard reads the integration event catalog from the backend. Built-in events currently include:

Event key	Meaning
sdk_init	SDK runtime initialized.
widget_loaded	Widget iframe loaded.
widget_open	Widget drawer opened.
widget_closed	Widget drawer closed.
post_open	Changelog or announcement post viewed.
cta_click	Post CTA clicked.
link_clicked	Widget link clicked.
home_contact_cta_clicked	Home Contact button clicked.
read_state_changed	Read state changed.
contact_submission_created	Contact form submission created.

Custom events come from the host app through the SDK. To route one to Slack or Discord, first create the matching active custom event trigger in the dashboard and bind its notification destinations as described above:

await window.releaseo.track("billing_limit_reached", {
  plan: "pro",
  source: "settings",
});

For PostHog, custom forwarding requires both the custom-events toggle and an explicit selected event subscription. For Webhook Out, each destination has its own subscription list. Slack and Discord notifications are bound from the event’s Notifications dialog, where you can also author the custom message.

PostHog

PostHog is a project-level destination configured from the dashboard. The backend stores the write-only project token, forwards selected events through the integrations worker, and can include identity payloads when enabled.

Typical setup:

1. Open Dashboard -> Integrations -> PostHog.
2. Add the PostHog API host and project token.
3. Choose whether to send events, identity payloads, and selected custom events.
4. Select the event subscriptions you want to forward.
5. Save and use the test action before enabling for production traffic.

Use a PostHog project token, not a personal API key.

Webhook Out

Webhook Out supports multiple destinations per project. Each destination has its own display name, stable destinationKey, endpoint URL, signing secret, status, rate limit, event subscriptions, test action, delivery logs, and secret rotation.

Common destination examples:

Destination	Endpoint example
Internal backend	https://api.example.com/releaseo/webhook
Zapier Catch Hook	https://hooks.zapier.com/hooks/catch/...
Make Custom Webhook	https://hook.eu1.make.com/...
n8n Webhook	https://n8n.example.com/webhook/releaseo

destinationKey is a lowercase identifier used in payloads and logs. Use letters, numbers, and hyphens, up to 40 characters. Reserved keys such as default and keys starting with reserved platform prefixes are blocked.

Webhook payload

Webhook payloads use a stable envelope:

{
  "version": 1,
  "type": "events",
  "deliveryId": "job_123",
  "connectionId": "conn_123",
  "destinationKey": "zapier-sales",
  "attempt": 1,
  "sentAt": "2026-05-15T10:30:00.000Z",
  "data": {
    "events": [
      {
        "name": "contact_submission_created",
        "canonicalName": "contact_submission_created",
        "isBuiltIn": true,
        "distinctId": "user_123",
        "url": "https://app.example.com/settings"
      }
    ]
  }
}

For identity delivery, type is identity and data.identify contains the identity payload. For a dashboard test, type is test.

Receiver checklist

Webhook Out is outbound from Releaseo to your endpoint. Your receiver should:

• accept POST requests with Content-Type: application/json
• read the raw request body before JSON parsing if your backend verifies signed requests
• reject stale requests according to your replay-window policy
• store delivery identifiers when you need retry deduplication
• return a 2xx status only after the event is accepted
• keep endpoint URLs stable, because destination logs and retries are scoped to the configured destination

Manage destinations, subscriptions, test sends, secret rotation, and logs from the Releaseo dashboard.