Collecting feedback through the API
Choose the right API intake mode for your forms and integrations, and preserve customer and source context.
Written By Markus Palm
Last updated 4 days ago
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.
For a supported call recorder, connect it directly to import transcripts without code.
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:
request is the default when you omit intakeMode. Use feedback when Autopilot should interpret the customer's words and connect them to Requests. Processing follows your Autopilot settings.
Send raw text and transcripts
In feedback mode, send the customer's words without rewriting them into a Request. A title is optional; if omitted, Featurebase uses the first line of the content.
Keep each submission within the API's input limit. Split longer transcripts into parts and give each part a different external identifier. Check the processing result after sending.
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.
Note: Author-only or company-only Requests need the customer identity required to apply those restrictions.
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.
Note: Set the source channel to where the feedback actually came from. The portal, widget, and Inbox channels are reserved for their native collection flows.
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, check the response before retrying:
queued- Processing has started; read the item back to check its resultskipped- Read the reason and check your Autopilot settingsexisting- This source was already received; inspect the returned item
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
Why does feedback intake reject a status or ETA?
Why does feedback intake reject a status or ETA?
Raw customer feedback carries no delivery decision yet. A status or an ETA describes a Request your team has already decided on, so the API refuses a feedback call that includes either instead of silently dropping it. Send intakeMode: 'request' when the record already has a status or ETA.
How do retries avoid creating duplicate Requests?
How do retries avoid creating duplicate Requests?
The API matches the external identifier in source. When your integration delivers the same identifier again, it returns the existing item instead of creating a second copy. The first delivery wins: a retry with different content does not rewrite an item your team may already have reviewed.
Who is the author if I send a source without a customer?
Who is the author if I send a source without a customer?
Featurebase uses a guest named after the source label or channel. Pass the customer as the author when the feedback belongs to a known person.
Why is my feedback text rejected as too long?
Why is my feedback text rejected as too long?
The API rejects an input that exceeds the applicable limit instead of processing only part of it. With AI processing enabled, the source limits are:
Call - 120,000 characters
Email or API - 60,000 characters
Slack or Discord - 30,000 characters
Split longer text into separate submissions. Other request-size limits can still apply when AI processing is off.
Was this helpful?
Still need help? Ask the team