DEV Community: anusha

I Built a One-Curl Audio Translator with Telnyx AI Inference

anusha — Tue, 14 Jul 2026 22:06:14 +0000

Localizing a podcast, translating a recorded meeting, or dubbing a lecture used to require three different services stitched together. The Telnyx AI Inference API exposes STT, chat completions, and TTS on the same private backbone, which means a single Flask app can run the whole pipeline.

The Telnyx code example is:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-content-translator-python

It is a Python Flask app you can clone and run in a few minutes. No phone number, no webhook tunnel, no background job runner.

The Flow

You POST an audio file plus a target language. The app calls Telnyx STT to transcribe the audio in the source language, calls AI Inference to translate the transcript with a TTS-friendly system prompt, and calls Telnyx TTS to render the translated text into audio. Long transcripts are chunked at sentence boundaries so the TTS model never gets an input larger than it supports, and the chunks are concatenated into one mp3.

The response includes the job id, both transcripts, and a URL you can curl to download the dubbed audio.

Why I Like This Example

It is small enough to demo live, but it covers the parts that often get cut from an audio translation demo:

File upload with multipart form data and a writable temp file
Three Telnyx AI endpoints chained together with per-stage error handling
Long-transcript chunking at sentence boundaries
Response shape handling for TTS endpoints that can return raw audio, JSON with base64, or JSON with a fetch URL
Temp file cleanup so the upload does not leak disk space
Auto language detection (or pinned language) depending on whether you trust STT's detection

The design choice I care most about is per-stage error handling. If the TTS call fails on chunk 3 of 8, the app returns 200 partial with the transcripts still intact, rather than throwing away the STT and translation work.

Run It Locally

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/ai-content-translator-python
cp .env.example .env
pip install -r requirements.txt
python app.py

Translate a Spanish clip into English:

curl -X POST http://localhost:5000/translate \
  -F audio=@spanish-sample.mp3 \
  -F source=es \
  -F target=en

Download the dubbed audio:

curl -OJ http://localhost:5000/translate/<job_id>/audio

Read the full transcripts:

curl http://localhost:5000/translate/<job_id> | python3 -m json.tool

What To Demo

I would keep the demo short:

Show the /languages endpoint to call out the supported set.
POST a Spanish audio file with target=en and walk through the response shape (job_id, transcript previews, audio_url).
Play the downloaded dubbed mp3.
Show GET /translate/<job_id> for the full transcripts.
(Optional) POST with source=auto to show language detection.

That gives viewers the full loop without getting lost in implementation details.

Where To Take It Next

The demo keeps translation jobs in memory for one hour. Production would replace the in-memory jobs dict with object storage (S3, GCS) for the audio blobs and a database (Postgres) for the metadata, run STT / translate / TTS in a queue, return 202 Accepted for long jobs, add API key auth, and cap upload size and audio length up front.

Resources

Code example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-content-translator-python
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx Developer Docs: https://developers.telnyx.com
Telnyx Portal: https://portal.telnyx.com

I Built an AI Subscription Cancel-Save Agent That Does Not Manipulate You

anusha — Tue, 14 Jul 2026 22:03:54 +0000

Cancel-save flows are easy to over-engineer into manipulative dark patterns, and easy to under-engineer into "your subscription has been cancelled, goodbye" experiences that lose revenue. A good cancel-save agent does three things: classifies the reason, offers one relevant save option, and respects a direct cancellation request.

The Telnyx code example is:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-subscription-cancel-save-retention-agent-python

It is a Python Flask app that combines Telnyx Voice, AI Inference, and Messaging into a small demo you can clone and run in a few minutes.

The Flow

A customer calls in saying they want to cancel. The Flask app receives the webhook, verifies the customer by caller ID, and asks why they want to cancel. AI Inference returns the reason (too_expensive, not_using, missing_feature, support_issue, competitor_switch, temporary_pause, other) and the sentiment. Hardcoded urgent phrases (lawyer, sue, fraud, chargeback) and direct cancel phrases (cancel now, please cancel my subscription) short-circuit before any offer.

Otherwise, the agent offers one save option from the OFFER_POLICY mapping. A "yes" applies the save or pauses the subscription. A "no" or "cancel" ends the call with a graceful cancellation. An ambiguous yes/no gets exactly one clarifying prompt — the agent never loops.

The case is recorded with the outcome (saved, cancelled, paused, transferred, needs_followup), and the customer record is updated. Hangups before resolution are recorded as needs_followup so reps can call back.

Why I Like This Example

It is small enough to demo live, but it covers the parts that often get cut from a "Hello World" voice AI demo:

Single-prompt AI Inference classification that returns structured JSON
An offer policy that maps reason to one offer and one default outcome
Hardcoded overrides for urgent phrases and direct cancel so the agent does not rely on the LLM to get safety right
One clarifying prompt on ambiguous yes/no so the conversation does not loop
Idempotent webhook handling so retries do not double-log cases
Hangup tracking so open cases never disappear

The design choice I care most about is non-manipulation. The agent does not push back on a direct cancellation, and it offers one save option — not five — when the customer is open to one. That maps to how good customer-success teams actually operate.

Run It Locally

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/ai-subscription-cancel-save-retention-agent-python
cp .env.example .env
pip install -r requirements.txt
python app.py

Expose the webhook:

ngrok http 5000

In the Telnyx Portal, set the Voice API app webhook URL to https://<ngrok-id>.ngrok-free.app/webhooks/voice. Seed a customer with POST /customers, then call the Telnyx number from the customer's phone.

What To Demo

I would keep the demo short and show three flows back-to-back:

Customer says "I want to cancel, it's too expensive" then accepts the 25% off offer. Case ends saved, customer status active.
Customer says "I want to cancel, it's too expensive" then declines. Case ends cancelled, customer status cancelled.
Customer says "I want a lawyer this is fraud." Case ends transferred, call moves to the human escalation number.

That gives viewers the full loop without getting lost in implementation details.

Where To Take It Next

The demo uses in-memory state, which is fine for learning. Production would wire the customer and case stores into your billing system (Stripe, Recurly, Chargebee) so a saved outcome actually applies the discount and a paused outcome defers the next invoice. Add consent recording (record_channels: "dual") for compliance audits, and replace the caller-ID match with a one-time code flow for real verification.

Resources

Code example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-subscription-cancel-save-retention-agent-python
Telnyx Voice docs: https://developers.telnyx.com/docs/voice/call-control
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx Portal: https://portal.telnyx.com

I Built a Hotel Concierge Line with Telnyx Voice, SMS, and Slack

anusha — Tue, 14 Jul 2026 21:45:33 +0000

Hotel guests do not care whether the front desk is staffed. They want to text or call one number and have their room service, housekeeping, concierge, or maintenance request handled. A concierge line is a good test case for voice AI because the workflow is familiar and the volume is real.

The Telnyx code example is:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/hotel-guest-services-python

It is a Python Flask app that combines Telnyx Voice, AI Inference, Messaging, and Slack into a small demo you can clone and run in a few minutes.

The Flow

A guest calls or texts the Telnyx number. The Flask app receives the webhook, looks up the room by caller ID, and either greets the guest by name or asks for the room number. Each request is sent to Telnyx AI Inference, which classifies it into room_service, housekeeping, concierge, or maintenance. Urgent phrases (fire, flood, leak, locked out, gas, medical) override the LLM and route the request as urgent.

The request is appended to a log, the guest gets an SMS confirmation, and staff get a Slack alert with the right emoji for the department. When staff mark the request complete, the guest gets another SMS.

Why I Like This Example

It is small enough to demo live, but it covers the parts that often get cut from a "Hello World" voice AI demo:

Caller-ID-based room lookup, with a regex-based fallback for unknown callers
A constrained JSON system prompt so the LLM returns structured output you can trust
An urgent-phrase override that does not depend on the LLM getting it right
Slack alerts that match the department
Idempotent webhook handling so retries do not double-log requests

That makes it useful as a starting template for any single-vertical phone service where one phone number handles a small set of structured requests.

Run It Locally

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/hotel-guest-services-python
cp .env.example .env
pip install -r requirements.txt
python app.py

Expose the webhook:

ngrok http 5000

In the Telnyx Portal, set the Voice API app webhook URL to https://<ngrok-id>.ngrok-free.app/webhooks/voice and the Messaging Profile inbound webhook URL to https://<ngrok-id>.ngrok-free.app/webhooks/sms. Call or text the Telnyx number to test.

What To Demo

I would keep the demo short:

Call from a phone matching room 205. Say "Can I order a club sandwich and a sparkling water please?"
Show the open request in curl http://localhost:5000/requests.
Show the Slack alert in the staff channel.
Mark it complete with curl -X POST http://localhost:5000/requests/0/complete.
Show the fulfilment SMS on the guest phone.

Then call from an unknown number, say "Room 205 please", and make a second request to show the unknown-caller path.

Where To Take It Next

The demo uses in-memory state, which is fine for learning. Production would replace ROOMS and service_requests with your PMS database (Opera, Mews, Cloudbeds), persist call state and event IDs to Redis, queue Slack and SMS side effects, add call recording for QA, and map urgent requests to a real paging system instead of Slack.

Resources

Code example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/hotel-guest-services-python
Telnyx Voice docs: https://developers.telnyx.com/docs/voice/call-control
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx Messaging docs: https://developers.telnyx.com/docs/messaging
Telnyx Portal: https://portal.telnyx.com

I Built an AI That Calls Candidates and Scores Them So Recruiters Don't Have To

anusha — Fri, 10 Jul 2026 20:44:38 +0000

The first-round phone screen is the most boring part of hiring.

A recruiter calls a candidate. Asks the same five questions. Takes notes. Decides whether to advance them. Does it again. And again. 200 times for one role.

That's a full week of screening calls before a single second-round interview.

So I built an AI that does that first call instead.

The AI calls the candidate. Conducts a 5-question screen. Hangs up. Produces a scorecard with scores, a recommendation, strengths, concerns, and a summary.

The candidate experience is just a phone call. They answer, talk to a friendly AI interviewer for two minutes, and hang up. No app, no form, no scheduling.

The recruiter's experience is a dashboard. They enter the candidate's name and phone number, click one button, and wait. A scorecard appears within 5 seconds of the call ending.

The code is here:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-hiring-phone-screen-python

The Problem With First-Round Screens

First-round screens are not hard. They are repetitive.

The same five questions. The same evaluation criteria. The same note-taking format. The same pass/hold/advance decision.

A recruiter doing first-round screens at 20 minutes each, for 200 applicants, spends 66 hours on calls before anyone advances. That's a week of work that produces the same structured output every time: name, background, skills, timeline, recommendation.

The first-round screen is also the part of hiring where the human adds the least value. The recruiter isn't evaluating technical depth. They're filtering for communication, basic fit, and interest. That's exactly the kind of structured conversation an AI can run consistently.

How It Works

The architecture has three pieces, and none of them are complicated.

One: trigger the call. The dashboard sends one API call to Telnyx scheduled events. The AI Assistant calls the candidate from a configured phone number.

Two: the call. Telnyx hosts the entire conversation. The AI Assistant (Voice Ultra Katie, powered by gpt-4o) greets the candidate, asks the five questions one at a time, listens, responds, and ends the call. No webhooks. No ngrok. No local call handling. Telnyx does the speech-to-text, the inference, and the text-to-speech in one managed product.

Three: the scorecard. The dashboard polls the Telnyx conversations API every few seconds. When it detects a finished screen conversation, it runs a second inference pass on the transcript to extract a structured scorecard: overall score, communication, technical depth, culture fit, recommendation (advance/hold/pass), key strengths, concerns, and a summary.

The scorecard appears in the dashboard within 5 seconds of the candidate hanging up.

Why AI Assistant Instead of Call Control

The original example in the Telnyx repo uses Call Control webhooks. That means you build the state machine yourself: answer the call, speak a greeting, gather speech, call inference, speak the response, gather again, repeat until done, hang up. You also need ngrok to expose your local server for webhooks.

I rebuilt it with the AI Assistant product instead. Telnyx hosts the entire call loop. You trigger the call, poll for the transcript, and process the result. Three API calls instead of a webhook state machine.

That tradeoff makes sense for this use case. The screening conversation is structured and predictable. You don't need fine-grained control over the call flow. You need the AI to ask five questions, listen, and hang up. That's what AI Assistants are built for.

If you needed custom call flow logic — DTMF menus, transfers, hold detection — you'd use Call Control. For a structured conversation with a known beginning and end, AI Assistants are simpler.

The Scorecard

The scorecard is the output. It's what the recruiter reads instead of taking the call themselves.

Each scorecard has:

Overall score (1-10)
Communication, technical depth, culture fit (each 1-10)
Recommendation — advance, hold, or pass
Key strengths — green chips ("strong communicator," "led multi-month infrastructure project")
Concerns — red chips ("salary range above band")
Summary — one paragraph the AI writes from the transcript

The scoring is a single inference call. The transcript goes in, the JSON comes out. Is it a validated rubric? No. It's an LLM's assessment of a conversation. But it's consistent — every candidate gets scored the same way, on the same criteria, from the same transcript.

For a real hiring pipeline, you'd want to calibrate the scoring prompt against historical data. For a demo, it works.

Where This Actually Works

This pattern works for high-volume, surface-level screening. Hourly roles, retail, seasonal hiring, call centers. Any role where the first-round screen is a filter, not a deep assessment.

It does not work for senior roles. The five questions are intentionally surface-level. They filter for communication and basic fit, not for engineering ability. A staff engineer would ace them in 30 seconds and you'd learn nothing.

It also doesn't replace human judgment. The recruiter reads the scorecard and decides whether to agree with the recommendation. The AI does the call. The human makes the decision.

Try It

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/ai-hiring-phone-screen-python
cp .env.example .env
pip install -r requirements.txt
python app.py

You need a Telnyx account, a phone number, and an API key. The example includes a bootstrap script that provisions everything automatically.

The Bigger Pattern

The interesting thing about this build isn't the hiring use case. It's the shape of the workflow.

An outbound call. A structured conversation. A structured output.

Replace "hiring screen" with "patient intake," "lead qualification," "customer feedback survey," "policy renewal check," or "appointment confirmation." The architecture is the same. The phone is the highest-conversion channel we already have — people answer calls. AI makes it scalable.

The first-round screen is just the most obvious place to start.

How I Built an AI Voicemail System in 118 Lines (And What Surprised Me)

anusha — Fri, 10 Jul 2026 17:15:29 +0000

Last weekend I got mad at voicemail. Not at any individual voicemail — at the entire concept. Someone calls, leaves a 30-second message, and then I have to remember to check it. By the time I do, the urgent ones are old news and the spam ones have wasted my attention. So I built an AI that listens for me.

This post is about the build — what I chose, what I got wrong, and the two specific decisions that turned a flaky demo into something I'm actually comfortable shipping.

The canonical code example is in the Telnyx code examples repo:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-voicemail-transcription-forwarding-python

Picking the example

Telnyx has a public repo of around 480 code examples. The vast majority are too complex for a six-minute demo. I needed something that was small enough to teach the pattern, real enough to be useful, and visual enough to work on camera.

I picked ai-voicemail-transcription-forwarding-python because:

It uses a recognizable, painful workflow. Everyone hates voicemail. No one has to be sold on why this matters.
It's small. Around 280 lines of real code after fixes. That's two screens of scrolling.
It has a clear "wow" moment. A phone call becomes an SMS with a priority emoji. That's the kind of thing you can show in five seconds and people get it.
It hits three Telnyx products in one app — voice, SMS, and AI Inference.

The first surprise: it didn't actually work

I cloned the example, filled in my API key, and the AI part worked great. Then I tested the SMS delivery. It failed. Every time.

The bug: the send_sms function was passing the caller's phone number as the from field. The owner's number was set as to. So the API was saying "send an SMS from this random number I don't own, to this number." Telnyx (correctly) rejects that.

This was in the upstream team-telnyx/telnyx-code-examples repo. It's listed as "production-ready." It is not production-ready. It would never have sent a single SMS in production.

I dug through the rest of the code and found twelve issues total. The takeaway was the same: read example code skeptically, even from authoritative sources.

The SDK method names were wrong

This one took me a while. The upstream example used client.calls.actions.record_start() and client.calls.actions.transcription_start(). Neither of those methods exist in the current Telnyx SDK. The actual names are start_recording() and start_transcription().

Even worse: start_recording() has a built-in transcription parameter. You can do recording + transcription in one call instead of two. The upstream example was doing it the hard way AND using wrong method names.

Then there was the language_code parameter on the speak() call. The SDK uses language, not language_code. The speak returned 200 but then a call.speak.failed webhook arrived with a 400 "not well-formed" error. The greeting never played.

The transcription arrives after hangup

This was the sneakiest bug. I assumed the transcription would stream in chunks via call.transcription webhooks while the caller was speaking. That's how the upstream example was written.

In reality, the transcription arrives as a single call.recording.transcription.saved webhook AFTER the caller hangs up, with the full text in a transcription_text field. Different event name, different payload structure, different timing.

The fix: the app now waits for the transcription on hangup instead of processing immediately. If the transcript arrives after the session is popped, it recreates the session and processes it.

The real production gotcha: Kimi reasoning eats your token budget

The first version used max_tokens=300 for the LLM call. It worked in my unit tests. It failed in production. The AI Inference call returned, but the JSON got truncated mid-word, like {"priority":"urgent","summary":"Sarah reports. Why?

Because the model — moonshotai/Kimi-K2.6 — has reasoning tokens. When you ask it to think step-by-step, the reasoning comes out of the same token budget as the answer. With max_tokens=300, my answer was getting cut off after the first ~50 tokens of actual JSON because Kimi had burned 250 tokens reasoning about whether it should return JSON.

The fix was bumping max_tokens to 1500. Rule of thumb: when using reasoning models, budget 5-10x more tokens than the visible output needs.

The voice quality problem

The upstream example used voice="female" which is the basic TTS tier. It sounded robotic. I upgraded to AWS.Polly.Joanna-Neural with service_level="premium" — a natural, human-like voice. One parameter change, dramatic quality difference.

What I'd do differently

A few things I'd change if I was starting over:

Skip Flask, use a single-file approach with stdlib. The app is small enough that Flask is overkill.
Use a real prompt framework. I hardcoded the prompt as a string. For a real product I'd want a prompt file with version control, A/B testing, eval set.
Add a recording-storage step. The carrier records the voicemail to an MP3. I don't subscribe to the call.recording.saved webhook, so the audio is just sitting in Telnyx's storage with no way to retrieve it from my app.

The thing I'm still figuring out

The hardest part wasn't the code. It was figuring out what the AI should actually decide. "Urgent vs normal vs spam" feels obvious, but the edge cases are where the value is:

A voicemail from your spouse saying "don't forget to pick up milk" — normal or spam?
A sales call that says "I just wanted to introduce myself" — spam or normal?
A "happy birthday" message with no other content — what category?

I haven't solved this. The next iteration would be a small eval set — twenty voicemails with my labels — and a prompt I tune against it.

What's next

This is the first of three apps I'm building for a YouTube series. The next one is an AI language tutor — call a phone number, practice a foreign language with an AI that adapts to your level. Same skeleton. By the third video, the audience will have seen the pattern three times and should be able to build anything on top of it.

If you want to build the voicemail yourself, the repo has the full code. The state machine itself fits in one screen — the rest is error handling, logging, and JSON parsing defenses. Should take you 30 minutes including the inevitable debugging.

I Built an RSVP Phone Line Because Nobody Fills Out Forms

anusha — Fri, 10 Jul 2026 16:31:29 +0000

Every event I have organized has the same problem. I send the invites. People say they will RSVP later. They don't. Three days before the event, I still don't know if I'm feeding 12 people or 40.

I built a form. It got a 30% response rate. I sent a Slack reminder. It got 50%. I called people on the phone. It got 90%+.

So I stopped building forms and built a phone number instead.

The code is here:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-event-rsvp-phone-line-python

The Idea

An RSVP line is just a phone number. You dial it. An AI agent picks up, asks for your name, your party size, your dietary restrictions, and any accessibility needs. It confirms everything back to you. You hang up. Within 30 seconds, your RSVP shows up in a dashboard as a row of structured JSON.

No form. No app to download. No link to click. Just a phone number.

The phone wins for RSVPs because it puts the friction on the wrong side. A web form asks the guest to find the link, open a browser, type their name, select a dropdown, click submit, and hope it worked. Every step is a chance to abandon. A phone call asks the guest to do one thing: answer the phone. They already know how to do that.

The conversion difference is not marginal. It is the difference between chasing 80% of your guest list and chasing 0% of them.

The Architecture

Two Telnyx products do the work.

The first is the Telnyx AI Assistant. It is a managed AI assistant with a system prompt, a greeting, a voice, and telephony settings. Telnyx hosts the entire call — speech-to-text, LLM reasoning, text-to-speech. No webhook loop, no ngrok tunnel, no signature verification. The assistant just talks to the caller.

The second is the Telnyx Conversations API. After the call ends, the conversation transcript is available via this API. A small Flask dashboard polls it every 5 seconds, finds new conversations from the RSVP assistant, and runs a second inference call to extract a structured RSVP — name, guests, dietary, accessibility, confirmed — from the transcript.

The flow:

caller dials the RSVP number
        |
        v
Telnyx AI Assistant picks up (Voice Ultra Katie, gpt-4o)
        |
        v
conversation: STT -> LLM -> TTS, looped
        |
        v
caller hangs up -> conversation stored on Telnyx
        |
        v
dashboard polls Conversations API every 5s
        |
        v
second inference call extracts structured RSVP JSON
        |
        v
RSVP appears in the dashboard table

The key design choice is that the dashboard does not participate in the call. Telnyx owns the call lifecycle. The dashboard is a read-only polling client that pulls transcripts and extracts structured data. The RSVP line works even if the dashboard is not running. The dashboard just shows what already happened.

That separation is what makes this reliable enough to demo live. No tunnel to break. No webhook signature to verify. No Flask loop to debug. Telnyx hosts everything.

The Prompt That Does the Work

The assistant's system prompt is deliberately simple:

you are the rsvp line for the gala on saturday july 26th at 7:00 pm
at the grand ballroom 123 market st san francisco.
dress code is black tie.

collect these details one at a time in order:
1) the caller's full name
2) number of guests including the caller
3) dietary restrictions (vegetarian vegan gluten-free allergies or none)
4) any accessibility needs

be warm friendly and excited.
keep each reply to one or two sentences.
confirm all details with the caller before ending.

when all details are collected and the caller confirms,
say a warm goodbye and wish them a great evening.

Lowercase. No exclamation marks. This is a Telnyx AI Assistant convention — lowercase prompts process more reliably and exclamation marks cause TTS to over-emphasize.

The prompt enforces order. Name first, then party size, then dietary, then accessibility. This makes the conversation predictable and the extraction reliable.

The Extraction Step

After the call ends, the dashboard runs a second inference call to turn the transcript into JSON:

Extract a structured RSVP from the call transcript below.
Return ONLY valid JSON with these exact fields:
- name (string or null)
- guests (integer or null)
- dietary (list of strings, empty list if none)
- accessibility (string or null)
- confirmed (boolean — true only if the caller explicitly confirmed the details)

Do not include any explanation or markdown. JSON only.

This is the key to the whole workflow. The conversation is free-form natural language. The extraction is rigid structured data. The two are separated by design. The conversation does not need to produce JSON. The extraction does not need to hold a conversation.

This separation makes the system robust to prompt drift. If the assistant rephrases a question, the extraction still works because it is looking at the full transcript, not a single response.

The Race Condition I Had to Fix

The first version of the dashboard had a bug. The polling loop fetched conversations, then fetched their messages. If the messages endpoint returned an error (because the conversation was still in progress, or the messages were not fully populated yet), the code added the conversation ID to a "seen" set and never retried it.

That meant a call that was in progress when the poller ran would never be picked up, even after it ended. The conversation was permanently blacklisted by a transient failure.

The fix was to only blacklist a conversation after confirming it does not belong to the assistant, or after the call has ended with too-short content. Transient failures and in-progress calls are retried on the next poll cycle.

There was also a timezone bug. The poller used time.mktime() to parse the conversation's last_message_at timestamp, but Telnyx timestamps are in UTC (the Z suffix). time.mktime() interprets as local time, so every conversation appeared to be 7 hours in the future, and the "is this call old enough to process?" check always returned false. The fix was to use calendar.timegm() which interprets as UTC.

These are the kinds of bugs that only show up in production. The example in the repo has both fixes applied.

What This Is Not

This is not a full event management platform. It is a single example showing how to use a Telnyx AI Assistant as an inbound data-collection agent. The RSVPs are stored in memory. There is no authentication. There is no multi-event support. There is no SMS confirmation.

But the shape is right. Swap the in-memory list for Postgres. Add SMS confirmation via Telnyx Messaging. Add per-event TeXML apps with dynamic prompt templates. Add A/B-tested greetings. The architecture scales because the call and the dashboard are decoupled.

The Point

The point is the pattern. A phone number, an AI assistant, a polling dashboard. No forms. No friction. Just the channel that already has a 90%+ answer rate.

Nobody should fill out an Eventbrite form for a 12-person dinner.

The code is here:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-event-rsvp-phone-line-python

Clone it, set your Telnyx API key, run it. The phone number is the RSVP line. The dashboard is the guest list. That's it.

I Built a Phone Number That Controls Simulated Facility Equipment

anusha — Wed, 01 Jul 2026 23:34:32 +0000

Most voice AI examples are conversational. A user talks to an assistant, the assistant responds, and the demo ends there.

I wanted something more tactile: call a phone number, say a command, and see a system change.

So this example turns a Telnyx phone number into a voice-controlled facility command line. You call in and say things like:

unlock the loading dock gate
turn on the warehouse lights
check the freezer alarm

The app listens, maps the spoken request to a simulated IoT device, updates state, logs the command, and speaks back the result.

The Basic Flow

The app is a small Python Flask service.

When someone calls the Telnyx number:

Telnyx sends a Call Control webhook to Flask.
The app answers the call.
Telnyx AI gather captures the caller's spoken command.
The app parses the command into a device and action.
The app updates simulated device state.
Telnyx speaks a short confirmation.
The command appears in an audit log.

The important part is that the result is visible. You can keep /devices open during the demo and refresh it after each command.

Why Use a Local Parser in the Live Call

The app includes a Telnyx AI Inference path for parsing commands through the local HTTP API. That is useful for showing how the pattern can handle broader natural language.

For the live phone call, responsiveness matters more. After Telnyx AI gather captures the command, the app uses a deterministic parser for known demo phrases. That avoids a second AI call and makes the phone experience feel faster.

This is a useful production lesson: not every part of a voice AI system needs to be generative. Use AI where it adds flexibility, and use deterministic logic where latency and reliability matter.

What This Could Become

The current app uses simulated devices:

loading dock gate
warehouse lights
freezer alarm
backup generator
irrigation pump

In production, the same pattern could connect to real systems:

building access control
field equipment
fleet devices
industrial alerts
facilities operations

For risky actions, you would add caller authentication, allowlists, and confirmation steps. You would also store command logs in a database and keep webhook signature verification enabled.

Demo Script

Open /devices.

Call the number.

Say:

unlock the loading dock gate

Refresh /devices and show the gate is unlocked.

Then say:

turn on the warehouse lights

Refresh again and show the lights are on.

Open /commands to show the audit log.

That is the full story: voice input, command parsing, state change, spoken confirmation, and an audit trail.

I Built a Web Chatbot with a Telnyx AI Assistant

anusha — Tue, 30 Jun 2026 20:19:15 +0000

Most AI assistant demos jump straight to voice. Voice is great, but a web chat is often the cleanest place to start.

You can prove the core idea quickly: configure an assistant in the Portal, send it user messages through the API, and render the response in your own interface.

The Telnyx code example for this is:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/chat-with-ai-assistant-python

The Idea

The assistant lives in Telnyx. The UI lives in your app.

That split is useful. Product teams can tune the assistant instructions in the Telnyx Mission Control Portal, while developers keep full control over the frontend, authentication, routing, styling, logging, and product-specific behavior.

For this demo, I used the assistant as a Telnyx Chatbot. It answers questions like what Telnyx does, what a Frankenstack is, and how AI Assistants fit into programmable communications.

The Flow

The app is a small Flask server with a browser UI.

When the page loads, the backend creates a Telnyx conversation. When the user sends a message, the backend sends that message to the Assistant Chat API. The assistant response comes back as text and the UI renders it in the chat window.

The important part is that the API key stays on the server. The browser only talks to the Flask app.

Why This Demo Works

This is a good first AI Assistant project because there is no phone number setup, no webhook tunnel, and no call-control state machine. You can focus on the assistant lifecycle:

create conversation
send message
render response
continue conversation

That makes it easier to explain the difference between a Portal-managed assistant and a raw model completion. The assistant has configuration, instructions, conversation context, and product-level settings. Your app just decides where and how that assistant shows up.

Running It

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/chat-with-ai-assistant-python
cp .env.example .env
pip install -r requirements.txt
python app.py

Environment:

TELNYX_API_KEY=your_telnyx_api_key
AI_ASSISTANT_ID=your_ai_assistant_id
PORT=5000

Open the local app and ask:

What is Telnyx?

Then ask:

What is a Frankenstack?

Those two questions make the demo easy to understand. Telnyx is the integrated communications and AI platform; a Frankenstack is what happens when teams stitch together separate vendors for telephony, speech-to-text, LLMs, text-to-speech, messaging, analytics, and workflows.

What I Would Add Next

For a real product, I would add user accounts, persistent conversation history, analytics, rate limits, and a handoff path to a human or support workflow. If the same assistant also powers voice or messaging, I would keep the assistant's core instructions consistent and let each channel handle its own UX.

That is the nice part of this pattern: one assistant can power multiple user experiences, and the app decides how the experience feels.

Resources

Code example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/chat-with-ai-assistant-python
Telnyx AI Assistants: https://telnyx.com/ai-assistants
Telnyx developer docs: https://developers.telnyx.com/docs/overview

I Built a Restaurant Reservation Voice Agent with Telnyx

anusha — Tue, 30 Jun 2026 18:57:07 +0000

Restaurant calls are a good test case for voice ai because the workflow is familiar: answer the phone, ask a few questions, confirm the booking, and send a text message.

The Telnyx code example for this is:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-restaurant-reservation-voice-agent-python

It is a Python Flask app that combines Voice AI, AI Inference, and SMS/MMS in one small demo.

The Flow

The caller dials a Telnyx number. Telnyx sends the call event to a webhook. The app answers, speaks a greeting, gathers speech, sends the caller's words to Telnyx AI Inference, speaks the response back, and repeats until the reservation is complete.

When the booking is confirmed, the app sends an SMS confirmation.

That is the interesting part: this is not just a chatbot. It is a phone workflow with voice input, ai reasoning, spoken output, and a messaging follow-up.

Why I Like This Example

It is simple enough to demo quickly, but it still maps to real developer questions:

how do i answer an inbound phone call with code?
how do i collect speech from a caller?
how do i use ai to decide what to say next?
how do i send an sms after a call?
how do i inspect what happened after the demo?

The /reservations endpoint is useful because it gives the audience something visible after the call. The SMS confirmation gives the demo a clear finish.

Run It Locally

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/ai-restaurant-reservation-voice-agent-python
cp .env.example .env
pip install -r requirements.txt
python app.py

Then expose the webhook:

ngrok http 5000

In the Telnyx Portal, point your Voice API application webhook to:

https://<ngrok-id>.ngrok-free.app/webhooks/voice

Assign a Telnyx number to that Voice API application and call the number.

What To Demo

I would keep the demo short:

Show the Voice API app webhook.
Call the number.
Book a table.
Show the SMS confirmation.
Open /reservations.

That gives viewers the full loop without getting lost in implementation details.

Where To Take It Next

The demo uses in-memory state, which is perfect for learning. The next production steps are database storage, availability checks, webhook verification, and a real reservation system integration.

The important thing is that the skeleton is already there: voice in, ai decision, voice out, and SMS follow-up.

Resources

Code example: https://github.com/team-telnyx/telnyx-code-examples/tree/main/ai-restaurant-reservation-voice-agent-python
Telnyx Voice docs: https://developers.telnyx.com/docs/voice
Telnyx AI Inference docs: https://developers.telnyx.com/docs/inference
Telnyx Messaging docs: https://developers.telnyx.com/docs/messaging

Building Voice AI Workflows with Branches Instead of One Giant Prompt

anusha — Fri, 26 Jun 2026 16:54:07 +0000

I built a Telnyx Conversational Workflows example for auto insurance claim intake.

The main idea is simple: when a voice agent has to do a lot, one big prompt can get hard to manage.

For intake calls, there are usually a bunch of paths to handle:

missing information
safety checks
fallback paths
priority follow-up
backend tool calls

This example models the call as a workflow instead of putting everything into one prompt.

The workflow handles the conversation path. A small Node.js/Express backend exposes tool endpoints for structured actions:

POST /tools/create-claim-intake
POST /tools/log-claim-intake-fallback
POST /tools/flag-priority-follow-up
GET /health

I like this pattern because it makes the flow easier to inspect. You can see the nodes, branches, and tool calls instead of trying to debug everything from prompt behavior.

Run it:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/build-conversational-workflow-nodejs
cp .env.example .env
npm install
npm test
node server.js

Code example:

[https://github.com/team-telnyx/telnyx-code-examples/tree/main/build-conversational-workflow-nodejs]

Building a Reusable Voice Agent with Runtime Configuration

anusha — Fri, 26 Jun 2026 16:38:56 +0000

I built a small Telnyx Voice example around a pattern I keep running into: one voice agent, multiple business contexts.
For appointment scheduling, a dental office, medical clinic, and physical therapy practice often need the same basic call flow. The assistant still answers the call, collects appointment details, and confirms the next step.

What changes is the business context: name, hours, services, tone, and greeting.

Instead of creating a separate assistant for every business, this example uses one reusable base assistant and applies runtime instructions when the call starts.

The flow is:

Caller dials a Telnyx number.
The webhook checks which number was called.
The number maps to a business config.
The server renders the right instructions and greeting.
Telnyx starts the assistant with that runtime context.

That makes it easier to reuse one assistant pattern across multiple businesses without copying the whole assistant setup.

Run it:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/provisional-telnyx-voice-api-agents-nodejs
npm install
cp .env.example .env
npm run dev

You can also preview a generated payload:
npm run preview -- smile-dental

Code example:
[https://github.com/team-telnyx/telnyx-code-examples/tree/main/provisional-telnyx-voice-api-agents-nodejs]

Outbound Voice Agent that Drops Out on Hold and Rejoins When a Human Answers

anusha — Fri, 26 Jun 2026 16:11:34 +0000

Outbound hold agent with Telnyx Voice

This Python example shows how to handle outbound calls where the agent has to wait on hold. It places an outbound call, uses an assistant for IVR/menu navigation, pauses during hold, and resumes when a human representative answers.

[https://github.com/team-telnyx/telnyx-code-examples/tree/main/outbound-hold-agent-python]

Check out the full example here.

DEV Community: anusha

I Built a One-Curl Audio Translator with Telnyx AI Inference

The Flow

Why I Like This Example

Run It Locally

What To Demo

Where To Take It Next

Resources

I Built an AI Subscription Cancel-Save Agent That Does Not Manipulate You

The Flow

Why I Like This Example

Run It Locally

What To Demo

Where To Take It Next

Resources

I Built a Hotel Concierge Line with Telnyx Voice, SMS, and Slack

The Flow

Why I Like This Example

Run It Locally

What To Demo

Where To Take It Next

Resources

I Built an AI That Calls Candidates and Scores Them So Recruiters Don't Have To

The Problem With First-Round Screens

How It Works

Why AI Assistant Instead of Call Control

The Scorecard

Where This Actually Works

Try It

The Bigger Pattern

How I Built an AI Voicemail System in 118 Lines (And What Surprised Me)

Picking the example

The first surprise: it didn't actually work

The SDK method names were wrong

The transcription arrives after hangup

The real production gotcha: Kimi reasoning eats your token budget

The voice quality problem

What I'd do differently

The thing I'm still figuring out

What's next

I Built an RSVP Phone Line Because Nobody Fills Out Forms

The Idea

The Architecture

The Prompt That Does the Work

The Extraction Step

The Race Condition I Had to Fix

What This Is Not

The Point

I Built a Phone Number That Controls Simulated Facility Equipment

The Basic Flow

Why Use a Local Parser in the Live Call

What This Could Become

Demo Script

Links

I Built a Web Chatbot with a Telnyx AI Assistant

The Idea

The Flow

Why This Demo Works

Running It

What I Would Add Next

Resources

I Built a Restaurant Reservation Voice Agent with Telnyx

The Flow

Why I Like This Example

Run It Locally

What To Demo

Where To Take It Next

Resources

Building Voice AI Workflows with Branches Instead of One Giant Prompt

Building a Reusable Voice Agent with Runtime Configuration

Outbound Voice Agent that Drops Out on Hold and Rejoins When a Human Answers