Overview

Use the Featurebase API to collect feedback from your own forms, products, and tools. Your integration can create a Request directly or send raw customer feedback, from a single message to a full call transcript, for your Requests workflow to process.

Your developer can find API access in Settings → Workspace → Developers → API. Use the API guide for authentication, the API reference for endpoint details, and webhooks when your integration must react to Request changes.

Choose direct Requests or feedback intake

Choose the intake mode according to what your integration sends:

If you omit intakeMode, the API uses request, so existing integrations keep creating Requests as before. A request call stores the text exactly as sent. A feedback call is processed like a portal submission and follows your Autopilot settings: with AI organization on, the text is organized into Requests; otherwise its asks are extracted and matched against existing Requests.

Send raw text and transcripts

In feedback mode, send the customer's words as they are. If you omit the title, the first line of the content becomes the title.

The text is read whole or rejected. The character limit follows the source channel you declare: 120,000 for call, 60,000 for email and api, and 30,000 for slack and discord. Split longer text into parts and give each part its own external identifier.

Featurebase reads long text in parts and then files each ask it finds: seconds for a short message, tens of minutes for a two-hour transcript. A repeated ask is reported once, and one submission produces at most 30 Requests.

Prepare categories and customer identity

Set up the categories you want the integration to use. Include the appropriate category and required form values in the Request.

Pass the customer as the author when the feedback belongs to a specific person. This preserves the distinction between the API user performing the action and the customer who requested it.

Decide the intended Request visibility before sending data.

Preserve the original source

Include source information when feedback came from another system. The source records the channel and an external identifier, and can also carry a URL, a conversation identifier, and a label such as the meeting or ticket name. This helps your team return to the original context.

Use an external identifier that stays the same when your integration retries the same source item. The API recognizes that source instead of creating another copy on each delivery.

When you send a source but no author, the item is attributed to a guest named after the source label or channel, not to the API key. In Triage, a Request organized from relayed feedback shows the declared channel and label, for example Call · Quarterly review.

Check the processing result and visibility

Test both the API response and the resulting item in Featurebase. Confirm:

• The Request or feedback has the expected title and content

• The author is the intended customer

• The category and form values are correct

• The source link opens the right item

• The Request is visible to the intended audience

For feedback intake, the response reports a processing status: queued when an AI run has started, skipped with a reason such as Autopilot being off, or existing when the delivery was a retry. Read the item back through the API to see where the feedback ended up. The status becomes processing, complete, or needs_review, and the results list each ask found in the text with its outcome:

• Request: The ask became a Request of its own

• Attached: It was added as evidence to an existing Request

• Held: It became a Request waiting for a teammate to publish it

• Question: It asked something; no Request was created, and a teammate answers it

Also check the result in Featurebase after processing. Do not assume every raw submission becomes a new public Request: it can be organized or connected to existing work according to your settings.

FAQs