I Built Bots That Do Things: Heres My Secret

Hey everyone, Marcus here from ai7bot.com. Today, I want to dive into something that’s been buzzing around my brain for a while, especially as I’ve watched the bot-building scene evolve over the past year or two. We’re not talking about your grandma’s simple FAQ bot anymore. We’re talking about bots that can really do things, bots that interact with external services in ways that feel almost magical to the end-user. And at the heart of making that magic happen? The humble, yet incredibly powerful, API.

Specifically, I want to talk about how we, as bot builders, can stop just reacting to APIs and start orchestrating them. I’ve seen too many bots that are essentially just wrappers around a single API endpoint – you ask it for weather, it calls the weather API, it gives you weather. Useful, sure, but a bit… one-dimensional. What if we could chain multiple API calls together? What if our bot could intelligently decide which APIs to call based on a more complex user request? That’s where the real juice is, and that’s what I’m calling “API Choreography for Bots.”

Beyond the Single Endpoint: Why Choreography Matters

My journey into this started about six months ago. I was building a bot for a small e-commerce client – let’s call them “GadgetHub.” Their initial request was pretty standard: “We want a bot that can show product details and track orders.” Easy enough, right? Connect to their product API, connect to their order API. Done. But then the client, bless their ambitious hearts, dropped a bombshell: “Could the bot also suggest complementary products based on what the user is looking at, and maybe even check if a specific product is in stock at their nearest physical store?”

Suddenly, my simple two-API bot was looking a lot more complex. I needed to:

• Get product details (Product API)
• Based on those details, find related products (Recommendation API – which was a separate service)
• If the user asked for local stock, figure out their location (Geolocation API)
• Then, query the inventory system for that specific store (Inventory API)
• And finally, present all this information in a coherent, conversational way.

This wasn’t just calling one API after another; it was a dance. The bot needed to know when to lead, when to follow, and when to bring in another dancer. That’s choreography. If I had just built a bunch of independent “skills” for each API, the conversation would have been clunky and broken. The user would have to explicitly say, “Hey bot, show me related products,” then “Hey bot, check stock for this,” and it would feel less like a helpful assistant and more like a glorified command-line interface.

The Pitfalls of Poor API Integration

Before we dive into the good stuff, let’s quickly touch on what happens when you *don’t* choreograph your APIs:

1. Fragmented User Experience: The bot feels like it has multiple personalities. It can answer one question well, but struggles to connect the dots between related queries.
2. Increased Development Time: Each new feature becomes an isolated piece of logic, leading to duplicated effort and brittle code.
3. Maintenance Nightmares: If one API changes, you might have to re-evaluate and rewrite multiple bot flows.
4. Limited Scalability: Adding new API integrations becomes a game of “how many more IF statements can I cram in here?”

I’ve been there. My early bots were a spaghetti mess of API calls triggered by keywords. It worked for simple stuff, but it didn’t *scale*. And in bot building, if it doesn’t scale, it’s already obsolete.

Orchestrating the API Dance: Practical Approaches

So, how do we get good at this? How do we make our bots graceful API choreographers? Here are a few techniques I’ve found incredibly useful.

1. State Management is Your Best Friend

This is foundational. Your bot needs to remember what it’s done, what it’s learned, and what it still needs to do. For example, if a user asks, “What’s the weather like in London tomorrow?” your bot might first call a location API to confirm “London,” then a weather API. If the user then asks, “And what about the day after?” the bot needs to remember it’s still talking about London. Without good state management, you’re constantly asking the user for information they’ve already provided.

I typically use a session object or a database to store conversation context. For a simple example in Python, using a dictionary for session state:

# Assuming 'session_data' is a dictionary unique to each user's conversation

def handle_weather_request(user_message, session_data):
 location = extract_location(user_message)
 date = extract_date(user_message)

 if location:
 session_data['last_location'] = location
 else:
 location = session_data.get('last_location')

 if date:
 session_data['last_date'] = date
 else:
 date = session_data.get('last_date', 'today') # Default to today if not specified

 if not location:
 return "I need a location to check the weather. Where are you interested in?"

 # Call weather API
 weather_info = call_weather_api(location, date)
 return f"The weather in {location} {date} will be: {weather_info}"

# Example usage
# user_session = {}
# print(handle_weather_request("What's the weather in Paris?", user_session))
# print(handle_weather_request("And tomorrow?", user_session))

This simple example shows how session_data helps the bot remember “Paris” for the follow-up question. This is crucial for multi-step API interactions.

2. Intent-Driven API Selection

Modern bot frameworks are great at intent recognition. Don’t just use intents to trigger a single response; use them to trigger a *sequence* of API calls or a specific API “flow.”

For GadgetHub, if the user’s intent was view_product_details, the bot wouldn’t just call the product API. It would also set flags or variables that indicate it might next need to call the recommendation API or the inventory API, depending on subsequent user input.

Think of it like a decision tree. The initial intent gets you to the root, and subsequent user messages or API responses guide you down different branches, triggering more API calls as needed.

3. Asynchronous API Calls (When Performance Matters)

If you’re making multiple independent API calls, don’t wait for one to finish before starting the next. This is particularly relevant when dealing with services that might have some latency. If your bot needs to fetch product details and user reviews from two different APIs, and these calls don’t depend on each other’s output, fire them off concurrently.

In Python, the asyncio library is your friend here. I won’t go deep into it, but here’s a conceptual snippet:

import asyncio
import httpx # A modern async HTTP client

async def fetch_product_details(product_id):
 async with httpx.AsyncClient() as client:
 response = await client.get(f"https://api.gadgethub.com/products/{product_id}")
 return response.json()

async def fetch_product_reviews(product_id):
 async with httpx.AsyncClient() as client:
 response = await client.get(f"https://api.gadgethub.com/reviews/{product_id}")
 return response.json()

async def get_product_info_and_reviews(product_id):
 details_task = asyncio.create_task(fetch_product_details(product_id))
 reviews_task = asyncio.create_task(fetch_product_reviews(product_id))

 details = await details_task
 reviews = await reviews_task

 return {"details": details, "reviews": reviews}

# To run this:
# product_data = asyncio.run(get_product_info_and_reviews("XYZ123"))
# print(product_data)

This approach significantly speeds up response times, leading to a much snappier and more satisfying user experience.

4. Error Handling and Fallbacks

APIs fail. Networks glitch. Services go down. It’s an inevitable truth of the internet. A well-choreographed bot doesn’t just crash when an API call fails; it gracefully handles the error. This means:

• Retries: For transient network errors.
• Meaningful Error Messages: “I’m sorry, I couldn’t get product recommendations right now. Please try again later.” is much better than a generic “Error 500.”
• Fallback Mechanisms: Can you provide a default response? If the recommendation API fails, can you at least still show the product details? Or suggest the most popular products as a fallback?

For GadgetHub, if the inventory API timed out for a specific store, the bot would respond, “I’m having trouble checking stock at that store right now. Would you like me to check other locations, or perhaps you can call the store directly?” This keeps the conversation moving and provides alternative solutions, rather than a dead end.

My Personal Takeaway: It’s All About the User Journey

When I approach a new bot project now, I don’t start with “Which APIs do I need?” I start with “What’s the ideal user journey?” I map out the conversation flow, including all the twists and turns, the questions the bot might ask, and the information it needs to gather. Only then do I look at how APIs fit into that journey.

This user-centric approach forces me to think about API choreography from the outset. It’s not an afterthought; it’s an integral part of designing a truly intelligent and helpful bot.

For example, if a user wants to book a flight and then a hotel, my bot doesn’t just have two separate skills. It understands that after booking a flight, the user *might* want to book a hotel for the same destination and dates. It proactively asks, “Would you like me to find hotels in [destination] for [dates] now?” This is where the magic of choreography shines – anticipating needs and seamlessly linking services.

Actionable Takeaways for Your Next Bot Project

1. Map Your User Flows: Before you write a single line of API-calling code, draw out the complete conversational journey. Identify every point where external data is needed.
2. Design for State: Plan how your bot will remember context across multiple turns. This is critical for chaining API calls logically.
3. Embrace Asynchronicity: If your bot needs to fetch data from multiple independent sources, use async programming to improve response times.
4. Build Robust Error Handling: Assume APIs will fail. Implement retries, meaningful error messages, and fallback strategies to prevent frustrating dead ends.
5. Think Beyond Single Intents: Use your NLU to understand complex requests that might require multiple API interactions.
6. Modularize Your API Wrappers: Create dedicated modules or functions for each API you interact with. This keeps your code clean and easier to maintain when APIs change.

API choreography isn’t just a fancy term; it’s a fundamental shift in how we build bots. It’s about moving from simple request-response interactions to intelligent, multi-step conversations that feel natural and genuinely helpful. So, go forth, bot builders, and make your APIs dance!

🕒 Published: April 21, 2026