Before you write in
Most issues that reach support turn out to be configuration, and the answer is already on a page. Check these first, because they resolve the majority of reports:
- Troubleshooting is organized by symptom, not by subsystem. Start with the section matching what you saw.
- API errors lists every error code the API returns and what causes each one.
- Webhook retries covers deliveries that arrive late, twice, or not at all.
- Call outcomes explains why a call is classified the way it is.
If you have read the relevant page and the behavior still does not match, write in.
Where to send it
| Channel | Use it for | Notes |
|---|---|---|
| [email protected] | Anything | Email is the primary channel for all plans. |
| Chat bubble, bottom right of the dashboard | Quick questions with a documented answer | The bubble is itself a Finn answering support questions. It is good at pointing you at docs, not at inspecting your account. |
| Dedicated Slack channel with your CSM | Enterprise accounts | Set up during onboarding. |
Response times are not published as a contractual figure. Do not treat the chat bubble as an escalation path for a live incident.
What to include
An issue gets answered in one round trip when the person reading it can reproduce your view of the system without asking you for anything. That means identifiers, timestamps, and the gap between what you expected and what happened.
| Field | Why it matters |
|---|---|
| Deployment ID | Scopes the report to one deployment. Without it, nobody can look at the same calls you did. |
| Call ID | Pins the report to a single call, its transcript, and its extraction status. Include one even if the problem is intermittent. |
| Timestamp with timezone | Logs are searched by time. "Yesterday afternoon" is not searchable. |
| What you expected | Often the actual disagreement. State it as a sentence, not as a bug title. |
| What happened instead | Quote the exact error string or transcript line. Paraphrased errors send people to the wrong code path. |
| Screenshot | Required for anything visual in the dashboard. Include the full page, not a crop of the error. |
For API issues, add the request. Redact your key, keep everything else:
curl -i -X POST https://api.hirefinn.ai/v1/calls \
-H "Authorization: Bearer sk_live_REDACTED" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: 6f1c9a2e-4b7d-4a10-9f3e-2c8b5d1a7e04" \
-d '{
"finn_id": "finn_01H8XK",
"to": "+15551234567",
"from": "+15559876543"
}'
Send the response headers too. The -i flag above captures them. Request IDs in the response are how a report gets traced to a specific server-side event, and they are the difference between an answer and a follow-up question. See API conventions for what those headers contain.
For webhook issues, include the raw request body exactly as your endpoint received it, plus the signature header. Reserialized JSON will not verify, so a re-encoded body makes a signature problem impossible to diagnose. See Webhook security.
What will slow your issue down
- No identifiers. "Calls aren't going out" without a deployment ID cannot be investigated at all. It becomes a request for the deployment ID.
- A conclusion instead of an observation. "Your STT is broken" is a hypothesis. "The transcript shows
fourwhere the caller saidfor, call IDcall_..." is a report. - A batch of unrelated symptoms in one email. Each one gets tracked separately anyway. Send them separately.
- Screenshots of text. Paste error strings as text so they can be searched.
- Reports about a call with no recording. If recording is disabled for the Finn, there is no transcript and no post-call analysis to inspect. See Recording consent and Retention for what exists and for how long.
Data you should not send
Do not paste API keys, webhook signing secrets, or caller personal data into an email or the chat bubble. Send identifiers instead. Support can look up a call by ID without you forwarding its contents. If you believe a key has been exposed, rotate it first and then write in. See Authentication.
Reporting something that looks like a bug
If the behavior contradicts a documented statement, say which page and which line. That turns the report into either a product fix or a docs fix, and both are actionable. Check Changelog before writing: behavior that changed recently is listed there, and a change you did not expect is not always a defect.