Featurebase Integration
Connect Featurebase — your customer feedback, bug-report, and changelog hub — so that a post flagged as a real problem escalates straight into an Autoheal investigation, and so agents can read your Featurebase boards for context while they work.
The integration spans two Featurebase surfaces — the feedback boards (posts) and the support inbox (tickets and conversations) — and has two halves you can use either or both of:
- Alert source (webhook). When a post or ticket is created or updated, or a support conversation requests a handover, Featurebase sends a webhook to Autoheal. Autoheal turns that event into a single alert and can start an investigation from it — the "a real bug was filed / a customer needs help, go look into it" path.
- Data source (MCP tools). During any investigation, agents can list and read posts and their comments, read your changelog, and read support tickets, conversations, contacts and companies through the Featurebase API — useful for "has anyone else reported this?", "what shipped recently that could have caused this?" and "who is this customer and what did they say?".
Writes are opt-in and off by default. The read tools never modify anything. Agents can post an internal note on a support conversation, redact a note they posted, and write results back onto a ticket — but only when you configure a Featurebase Admin ID (below). Leave that field blank to keep the integration read-only. Autoheal only ever writes internal, teammate-only notes — it is not a customer-facing correspondent, so it never posts a reply the customer can see (the same stance the Jira and Jira Service Management integrations take). Every note is attributed to the dedicated Autoheal teammate, never a human.
Capabilities
Once connected, agents can:
| Capability | Description |
|---|---|
| Escalate flagged posts | A post.created / post.updated webhook becomes one alert (deduplicated per post), which your alert-response rules can auto-investigate |
| Escalate tickets & handovers | A ticket.created / ticket.updated / conversation.handover_requested webhook becomes one alert (deduplicated per ticket number) |
| List posts | Search and filter posts by board, status, tags, review state, and free text, sorted and cursor-paginated — featurebase_list_posts |
| Read a post | Fetch a single post's full detail by id — featurebase_get_post |
| Read comments | Pull the comment thread on a post — featurebase_get_comments |
| Read changelogs | List live/draft changelog entries — featurebase_list_changelogs |
| List boards / statuses | Enumerate boards and post statuses with their ids — featurebase_list_boards, featurebase_list_statuses |
| Read a ticket | Fetch a support ticket by its ticket number — featurebase_get_ticket |
| List / read conversations | List support conversations, or read one with its full thread — featurebase_list_conversations, featurebase_get_conversation |
| Read contact / company | Resolve who reported an issue (by contact id) and which tenant they belong to (by the company's internal id, read off the ticket or contact) — featurebase_get_contact, featurebase_get_company |
| List admins | Find the id of the Autoheal teammate for write attribution — featurebase_list_admins |
| Post internal note (opt-in) | Post a teammate-only internal note on a conversation (never customer-visible) — featurebase_post_conversation_note |
| Redact a note (opt-in) | Retract an internal note Autoheal posted in error — featurebase_redact_conversation_part |
| Update a ticket (opt-in) | Re-route, re-status, or backfill custom fields on a ticket — featurebase_update_ticket |
| Test connection | Verify the API key and base URL — featurebase_test_connection |
The write tools on this integration (post and redact internal notes, update tickets) are turned on at setup by the Featurebase Admin ID and are available only to agents granted write access to it. A governance policy on write operations pauses each write for a person to approve, and every call is recorded in the Audit Trail.
Agents read Featurebase through its API v2 (https://do.featurebase.app/v2), pinned to the date-versioned 2026-01-01.nova API. Board and status filters on featurebase_list_posts take ids, not names — agents use featurebase_list_boards / featurebase_list_statuses to resolve a name you mention (e.g. "the Bug board", "In Progress") to its id before filtering.
Prerequisites
- A Featurebase workspace on the Growth plan (or a Growth trial). The API, webhooks, and MCP access are Growth-plan features — on the Free plan the Developers area is paywalled and no API key can be created.
- An API key (Featurebase dashboard → Developers → API)
- For the webhook path: access to Featurebase Developers → Webhooks to create a webhook and copy its signing secret
Configuration Fields
| Field | Required | Description |
|---|---|---|
| API Key | Yes | Featurebase API key. Sent as the X-API-Key header on every read. Used by the data-source tools. |
| Webhook Signing Secret | No | The whsec_... secret Featurebase generates for your webhook. When set, Autoheal verifies every webhook's X-Webhook-Signature. Strongly recommended for the alert-source path. |
| Featurebase Admin ID | No | The Featurebase admin (teammate) id that Autoheal posts support-inbox internal notes as. Set it to enable the write tools; leave it blank to keep the integration read-only. Autoheal only ever writes internal, teammate-only notes — never a customer-facing reply. Create a dedicated "Autoheal" teammate in Featurebase, then get its id from featurebase_list_admins. |
| API Base URL | No | Defaults to https://do.featurebase.app/v2. Only change it if Featurebase gives you a different API host. |
Setup
In Featurebase, go to Developers → API and create an API key. Copy it — you'll paste it into Autoheal. (The Developers area requires the Growth plan; start a Growth trial if you don't see it.)
- Go to Integrations in Autoheal and click Featurebase.
- Enter a name (e.g. "Production Featurebase").
- Paste the API Key.
- In Featurebase, go to Developers → Webhooks and create a webhook pointing at the webhook URL shown in Autoheal.
- Subscribe it to the post.created and post.updated events (feedback boards). If you use the support inbox, also subscribe to ticket.created, ticket.updated and conversation.handover_requested.
- Copy the webhook's signing secret (
whsec_...) and paste it into the Webhook Signing Secret field in Autoheal.
To let Autoheal post internal notes and update tickets, create a dedicated Autoheal teammate in Featurebase, run the featurebase_list_admins tool to get its admin id, and paste that into the Featurebase Admin ID field. Skip this step to keep the integration read-only. (Autoheal only ever writes internal, teammate-only notes — it never posts a customer-facing reply.)
Click Test Connection to verify the API key, then Save. Create or update a test post on a subscribed board to confirm the webhook reaches Autoheal.
How the alert-source flow works
- A post is created or updated on a Featurebase board you subscribed the webhook to.
- Featurebase sends a signed webhook to Autoheal.
- Autoheal verifies the signature, then normalizes the post into a single alert (
source_system = featurebase). Redeliveries and later updates of the same post collapse onto one alert rather than fanning out into duplicates. - Your alert-response rules decide whether to auto-investigate — you can scope this to a specific board (match on the
featurebase_board_idlabel), so only your "Bug Reports" board escalates while a "Feature Requests" board does not. - An agent investigates using the post's title, body, board, and author as context, alongside your other connected integrations (logs, metrics, code).
A post whose status is one of Featurebase's terminal lifecycle types — Completed or Canceled (this covers a "Rejected" status, which is a canceled-type status) — is ingested as a resolved alert, so a webhook firing on an already-handled post doesn't wake triage. Common terminal status names (Complete, Closed, Resolved, Done, Shipped, Rejected) resolve as well.
Tickets and handovers follow the same flow on the support-inbox surface: a ticket.created / ticket.updated / conversation.handover_requested webhook becomes one alert deduplicated per ticket number (which equals the linked conversation id), carrying featurebase_ticket_number, featurebase_conversation_id, featurebase_category, featurebase_company_id, and featurebase_customer_priority / featurebase_internal_priority labels for routing. A terminal-status ticket resolves like a post, but a handover request always fires — it means a customer is explicitly waiting on a human. Customer-set priority maps onto the alert severity when present.
Support-inbox ingest is controlled entirely by your Featurebase webhook subscription: Autoheal produces ticket/handover alerts only for the events you subscribe the webhook to. ticket.updated in particular fires on every status, assignee, or field change, which on a busy inbox is far more volume than post.*. To scope or turn it off, unsubscribe the ticket.created / ticket.updated / conversation.handover_requested events in Featurebase (Developers → Webhooks) — or narrow which of them start an investigation with an alert-response rule.
Support tickets and conversations contain customer-supplied text. Agents
treat those message bodies as untrusted data to investigate, never as
instructions. Autoheal never posts a customer-facing reply — it only writes
internal, teammate-only notes, so a human stays in the loop on anything the
customer sees. The opt-in featurebase_update_ticket tool can re-route or
re-status a ticket; those changes are internal and reversible, but — like any
write — are reachable from injected text, so enable write-back only when you are
comfortable with that trade-off. Redaction is scoped to Autoheal's own internal
notes, so it can never remove a customer's message. When the write tools are
enabled, every internal note carries the Autoheal investigation link so the
thread has a clear audit trail.
Scope which posts escalate using an alert-response rule that matches on the
featurebase_board_id label — for example, only auto-investigate posts on your
bug board. This is the reliable matcher: every post carries its boardId, so
the rule always matches. Get the id from the board's settings in Featurebase or
from the featurebase_list_boards tool (it returns each board's id and name).
The featurebase_board label (the human board name) is only present when the
webhook payload expands the board object, so treat it as a best-effort fallback,
not the primary matcher.
Webhook Security
Featurebase signs each webhook with HMAC-SHA256 over "<timestamp>.<body>", sending the result in the X-Webhook-Signature header and the timestamp in X-Webhook-Timestamp. When you configure a signing secret, Autoheal:
- rejects any delivery whose signature is missing or doesn't verify (constant-time compare), and
- rejects a validly-signed but stale delivery (timestamp outside a 5-minute window), which blocks replay of a captured webhook.
If you leave the signing secret blank, Autoheal accepts unsigned deliveries and the URL secret is the only guard — a documented trade-off. Configuring the signing secret is strongly recommended.
Example Queries
Once connected, you can ask an agent questions like:
List open bug reports in Featurebase from the last week
Show me the comments on Featurebase post <id>
What changelog entries shipped in the last month?
Are there other Featurebase posts describing this same checkout error?
Troubleshooting
Test connection fails / 401 Unauthorized
- Confirm the API key is correct and active (re-copy it from Developers → API — a partial paste or trailing whitespace is the most common cause).
- Confirm your workspace is on the Growth plan; the API returns 401/403 for keys created before a plan lapsed.
- Confirm the API Base URL is
https://do.featurebase.app/v2unless Featurebase gave you a different host.
Webhook not arriving
- Verify the webhook URL in Featurebase matches the URL shown in Autoheal.
- Confirm the webhook is subscribed to post.created / post.updated.
- Create or update a post on a subscribed board to trigger a delivery.
Signature verification failed (401)
- Verify the Webhook Signing Secret matches the value Featurebase shows for the webhook, copied without extra whitespace.
- If the secret is configured in Autoheal, Featurebase must send a signature — an unsigned delivery is rejected.
- A "stale timestamp" rejection means the delivery's timestamp is more than 5 minutes off; check that the sending system's clock is correct.
A post didn't start an investigation
- Ingestion and auto-investigation are separate: the post becomes an alert, but your alert-response rules decide whether to investigate. Check the rule's matchers — use
featurebase_board_idto match a board (get the id fromfeaturebase_list_boards) andfeaturebase_status/featurebase_status_typefor status. - Posts in a terminal status (a Completed- or Canceled-type status, e.g. Complete/Closed/Resolved/Done/Shipped/Rejected) are ingested as resolved and won't trigger triage.
Rate limited (429)
- The read tools honor Featurebase's
Retry-Afterand back off automatically; very large boards simply take longer to page through.