No support tool operates in a vacuum. Your team already uses Slack for internal communication, project management tools for task tracking, and CRMs for customer data. Heedback integrates with your existing stack through native integrations, webhooks, and a REST API — so information flows where it needs to without manual copy-pasting.

Prerequisites

Before you begin, make sure you have:

A Heedback account with admin or owner permissions
Access to the tools you want to integrate (Slack workspace admin, webhook endpoint, etc.)
For API usage: familiarity with REST APIs and an HTTP client (cURL, Postman, or your language’s HTTP library)

Step 1: Connect Slack

Slack is the most popular integration, and Heedback supports it natively. Here’s how to set it up:

Go to Settings → Integrations in your Heedback dashboard.
Find Slack in the integrations list and click Connect.
You’ll be redirected to Slack’s OAuth authorization page. Select the workspace you want to connect and approve the permissions.
Back in Heedback, choose which Slack channel should receive notifications. You can pick an existing channel or create a dedicated one like #customer-support.
Configure which events trigger Slack messages — new conversations, new messages, status changes, or all of the above.

Once connected, your team gets real-time Slack notifications when customers reach out. Each notification includes the customer’s message, their profile info (if identified), and a direct link back to the conversation in Heedback.

Tip: Create a dedicated Slack channel for Heedback notifications. Mixing support alerts into a busy general channel means they’ll get buried.

Step 2: Configure Webhooks

Webhooks let you push Heedback events to any HTTP endpoint — your own backend, a serverless function, or an automation platform like Zapier or n8n.

Navigate to Settings → Webhooks and click Add Webhook. You’ll need to provide:

URL: The endpoint that will receive POST requests. It must be publicly accessible and return a 200 status code.
Events: Select which events trigger the webhook. Available events include:
- conversation.created — a new conversation is opened
- message.created — a new message is sent (by customer or agent)
- conversation.status_changed — a conversation is opened, closed, or snoozed
- post.created — a new feature request is submitted
- vote.created — a user votes on a feature request
Secret (optional but recommended): A shared secret used to sign webhook payloads. Verify the signature on your end to ensure requests genuinely come from Heedback.

Each webhook delivery includes a JSON payload with the event type, timestamp, and the full resource data. For example, a message.created event includes the message content, conversation ID, sender details, and organization context.

Step 3: Build with the REST API

For deeper integrations, Heedback provides a versioned REST API at /api/v1/. Common use cases include:

Syncing contacts: Pull end-user data into your CRM or push CRM updates back to Heedback.
Creating conversations programmatically: Trigger support conversations from events in your own app (e.g., a failed payment, an error alert).
Exporting data: Fetch conversations, messages, or feature board votes for reporting and analysis.

Authentication: API requests require a session cookie (for dashboard integrations) or an API key passed via the Authorization header. Generate API keys under Settings → API.

Example — Fetch all open conversations:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://your-heedback-instance.com/api/v1/conversations?status=open

The API follows REST conventions: resources are nouns, actions are HTTP verbs, and responses are JSON. Pagination uses page and limit query parameters.

Step 4: Automate with Zapier or n8n

If you prefer no-code automation, webhooks are the bridge between Heedback and platforms like Zapier, Make, or n8n.

Zapier example — Create a Jira ticket for every new feature request:

Create a Zap with a Webhooks by Zapier trigger (Catch Hook).
Copy the Zapier webhook URL and add it in Heedback’s webhook settings with the post.created event.
Add a Jira action step that creates a new issue using data from the webhook payload (title, description, voter count).
Turn on the Zap and test it by submitting a feature request in Heedback.

n8n example — Post a summary to Slack when a conversation is closed:

Create an n8n workflow with a Webhook trigger node.
Add a filter node to check that event === "conversation.status_changed" and status === "closed".
Add a Slack node that posts a summary (customer name, topic, resolution time) to your #support-wins channel.

Step 5: Monitor and Debug

Integrations can fail silently if endpoints go down or payloads change. Heedback helps you stay on top of it:

Webhook logs: Under Settings → Webhooks, each webhook shows a delivery log with status codes, response times, and payloads. Failed deliveries are highlighted in red.
Automatic retries: Failed webhook deliveries are retried up to 3 times with exponential backoff. If all retries fail, the webhook is flagged for your attention.
Test deliveries: Click Send Test on any webhook to trigger a sample payload. Use this to verify your endpoint is receiving and parsing data correctly before going live.

Tips and Best Practices

Start with Slack and one webhook. Don’t try to wire up everything at once. Get one integration working reliably, then expand.
Always verify webhook signatures. Without signature verification, anyone who discovers your endpoint URL could send fake events.
Use idempotent handlers. Webhook deliveries can occasionally be duplicated. Design your handlers to safely process the same event twice without side effects.
Keep API keys scoped and rotated. Don’t share a single API key across all integrations. Create separate keys for each use case so you can revoke one without breaking everything.

Notifications — Webhooks complement in-app and email notifications. Use webhooks for system-to-system automation, notifications for human-facing alerts.
Feature Boards — Webhook events for votes and feature requests let you pipe product feedback directly into your planning tools.
Support Inbox — The conversations that trigger webhook events originate here. A well-organized inbox makes integration data more meaningful.
Team Management — Control which team members can configure integrations through role-based permissions.