DEV Community: Animesh Gupta

Giving an AI Agent Real-World Buying Power in India: One API for Local Supply

Animesh Gupta — Tue, 14 Jul 2026 04:54:37 +0000

When developers start building AI agents that can "do things in the real world," the conversation usually gets to tool-calling fast. Give your agent a function, it calls the function, done. What the tutorials don't cover is what happens when the function needs to reach actual Indian local supply — a service provider in a specific city, a retail shop with live inventory, a hotel with room availability, a ride or bus booking — and do it reliably, across categories, in production.

That gap between "agent can call a function" and "agent can actually purchase local supply in India" is where most projects stall.

Why Indian Local Supply Is Structurally Hard to Access

Indian commerce at the local level is deeply fragmented. The supply you care about — neighbourhood services, local retail, accommodation inventory, mobility options — is distributed across dozens of provider rails, each with different APIs, authentication schemes, catalog formats, and order lifecycle semantics.

To build an agent (or any platform feature) that can search for a plumber in Bangalore, compare hotel rooms in Jaipur, order a product from a local retailer, and book a cab — you would need direct integrations with each rail separately. That means:

Multiple API contracts to negotiate and maintain
Different auth flows per provider category
Non-uniform catalog structures (what "search" returns looks different for retail vs. services vs. mobility)
Different order lifecycle primitives per domain (services have RFQ flows; retail has add-to-cart; mobility has select-then-confirm; accommodation has availability-then-book)
No unified way to express agent-friendly intents like "find options, get a quote, confirm if acceptable"

For a single-domain product, this is manageable. For any platform that wants to span categories — or for an AI agent that should be able to handle whatever the user asks for — it becomes an integration tax that compounds with every new domain.

What "Agentic Commerce" Actually Requires

The standard e-commerce API mental model (search → add to cart → checkout) doesn't map cleanly onto all supply categories. Services need RFQ flows — you describe what you need, the provider quotes a price, and you confirm if the quote is acceptable. Mobility needs a select-then-confirm pattern with dynamic pricing. Accommodation needs real-time availability queries with rate holds. Retail can work closer to the traditional cart model, but catalog freshness and local inventory make it different from a global e-commerce API.

For an AI agent to handle these flows gracefully, it needs primitives that match how supply actually works:

Search — express intent across category-appropriate dimensions (location, service type, dates, product category, etc.)
RFQ / Item Selection — identify specific provider options from search results
Quote — get binding or indicative pricing from a specific provider on a specific requirement
Order — initiate and confirm an order with terms agreed
Status / Lifecycle — track, cancel, or modify within the provider's allowed windows

These five primitives, unified across categories, are what make a supply API genuinely agent-friendly rather than just another REST API with a search endpoint bolted on.

The Integration Tax: What Maintaining Multiple Direct Rails Actually Costs

Imagine you're building a travel assistant agent. You want it to handle hotels, rides, and inter-city buses in India. Naively, that's three separate integration projects:

One with each hotel inventory source (each with its own availability format, rate structure, and booking confirmation flow)
One with each ride platform (each with its own fare estimation API and trip-confirmation webhook)
One with bus aggregator APIs (each with their own seat map format and PNR generation)

Each integration takes weeks to build correctly, and ongoing maintenance cost is real — API versions change, providers update auth schemes, catalog formats drift. When you're building an agent, you want to spend your time on the agent's reasoning, not on keeping a fragile integration layer alive.

The same tax applies to platforms embedding commerce features — a business operations platform that wants to let users book a service, a marketplace that wants to surface local retail, a B2B procurement tool that wants to reach verified suppliers. Each new supply category is another integration project.

What a Single Agentic-Commerce API Should Look Like

The value proposition of a supply aggregation API is straightforward: one integration, consistent primitives, supply spanning categories. But the implementation details matter a lot for whether it's genuinely usable for agent workflows.

What matters for developer and agent use:

Consistency across categories. Search should work with the same call structure whether you're looking for a service provider or a retail product. Order primitives should be predictable regardless of whether you're booking accommodation or a local delivery. Agents need deterministic interfaces — category-specific quirks should be handled by the API layer, not by the agent's reasoning loop.

Quote-before-commit flows. Many supply categories in India require getting a price quote before committing to an order. An agent that skips this and tries to jump straight to checkout will fail in practice. The API needs to expose RFQ/quote as first-class steps, not hide them.

Structured responses agents can act on. Not just human-readable text — structured JSON responses that an agent can parse, compare across options, and use to make decisions. Price, availability, provider metadata, terms all need to be machine-readable.

Honest error semantics. When supply isn't available, when a provider is offline, when a quote expires — the API should return structured errors that an agent can handle gracefully, not generic 500s.

Bino Supply API: One API for India Local Supply

Bino Supply API (public surface: boni.one/api-hub) is being built as a single agentic-commerce API giving developers, platforms, and AI agent builders access to Bino-native Indian local supply across categories — services, retail, accommodation, mobility, and more — through one consistent interface.

The intent is to solve the integration tax described above: instead of maintaining direct rails per supply category, you integrate once and get search, RFQ, quote, and order flows across categories through one API with consistent primitives.

A few things worth being direct about:

This is an emerging API, not a mature scaled platform. It is being packaged and positioned for early developers and builders who want to build on top of Indian local supply without the integration overhead. If you're building an AI agent that needs real-world purchasing capability in India, or a platform that wants to embed commerce features across categories, Bino Supply API is worth evaluating as a foundation — not as a fully-proven production scale infrastructure (yet).

The right early adopters are teams building agent workflows where India supply access is a required capability, platforms evaluating how to add agentic commerce features, and developers exploring what search-to-order across India's local economy can look like when it's API-accessible.

What to Think About When Evaluating This as Infrastructure

If you're a developer evaluating supply APIs for India, the questions that matter:

Coverage: Which categories are live vs. in-progress? For a general-purpose agent, breadth matters more than depth in any single category.

Primitive consistency: Can you learn one API shape and apply it across categories, or is each category a different integration effectively?

Quote/RFQ support: Does the API expose this as a first-class step, or do you have to build around it?

Structured responses: Are catalog items, pricing, and availability returned in formats an agent can directly consume and compare?

Lifecycle support: Can you track, cancel, and modify orders through the API, or does post-order management fall back to provider-specific flows?

Bino Supply API is being built around these questions as the design constraints. If you're early enough in your build to be evaluating infrastructure choices, it's worth looking at the API hub and getting in contact.

Summary

Giving an AI agent real-world buying power in India is a supply aggregation and API design problem more than a model problem. The model can reason about what the user wants; the hard part is giving it clean, consistent, category-spanning access to actual Indian supply through agent-friendly primitives.

Bino Supply API is one approach to this problem — a single API for search, RFQ, quotes, and order flows across local services, retail, accommodation, and mobility in India. It's an early-stage platform being built for developers who want to stop maintaining direct rails per supply category and start building on top of India's local economy through one consistent interface.

If you're building in this space, explore what's available at boni.one/api-hub.

How to Give Your LiveKit, Vapi, or Retell Voice Agent a Real Indian (+91) Phone Number

Animesh Gupta — Tue, 14 Jul 2026 04:52:21 +0000

The problem: your voice agent is ready, but India won't pick up

You have a working voice AI agent — maybe built on LiveKit Agents, Vapi, or Retell — and you need it to be reachable on a real Indian phone number. Not a virtual number from a gray-market SIM reseller. Not a US Twilio number with unreliable India routing. A legitimate +91 business inbound number that your users can call from any Indian mobile or landline.

Here is what the standard path looks like:

Find a licensed Indian telecom operator or ITSP (Internet Telephony Service Provider).
Submit KYC documents, company registration proof, sometimes a signed LOA (Letter of Authorization).
Wait days or weeks for number provisioning.
Receive SIP credentials — if you are lucky, a vague PDF with no webhook documentation.
Figure out on your own how to bridge that SIP trunk to your agent framework.
Hope the number actually works for inbound calls from BSNL, Jio, and Airtel.

Most developers building voice AI side projects or SaaS products hit a wall at step 2. And even teams that get through provisioning discover that Indian telecom providers have almost zero developer-friendly tooling: no webhook endpoints, no call logs via API, no programmable routing rules.

This article explains the underlying telecom concept (DID routing), how it should connect to a voice AI agent, and what a developer-first approach looks like.

What is a DID, and how does inbound call routing actually work?

DID stands for Direct Inward Dialing. It is a phone number leased from a telecom carrier that, instead of connecting to a physical phone line, routes inbound calls over SIP (Session Initiation Protocol) to a destination you configure — a SIP URI, a media server, a WebRTC gateway, or an HTTP webhook.

The routing chain for a typical voice AI agent looks like this:

Caller dials +91 XXXXX XXXXX
         |
   Telecom PSTN (Jio, Airtel, BSNL)
         |
   ITSP / DID provider  <-- this is the layer most teams lack
         |
   SIP trunk or webhook  <-- where your code takes over
         |
   Your voice agent (LiveKit, Vapi, Retell, Asterisk, etc.)
         |
   AI model + TTS/STT

The ITSP layer is the piece that turns a PSTN call into something a developer can interact with. A good DID provider exposes:

A SIP endpoint you can point at a media server (LiveKit SIP, FreeSWITCH, Asterisk)
A webhook that fires when a call arrives, letting you dynamically decide routing (transfer, drop to IVR, connect to agent)
Call detail records accessible via API so you can build billing logic or debug dropped calls
Fallback routing so calls do not silently fail if your agent is down

Most Indian telecom providers expose none of this. They provision the number and give you a SIP trunk — full stop. The webhook layer, the fallback logic, and the call logs are your problem.

Why Indian numbers specifically are harder than US numbers

If you have built voice agents targeting the US market, you are used to Twilio, Vonage, or Plivo — providers that are developer-first from day one with REST APIs, webhooks, and SDKs.

India has structural differences:

Regulatory layer. Inbound business numbers in India require TRAI-compliant provisioning. The operator must verify the entity behind the number. This is not optional — it is what makes the number legitimate and ensures it works across all Indian carriers.

PSTN interconnect complexity. India has fragmented carrier interconnects. A number that works on Jio may not route cleanly from BSNL or a rural landline without proper carrier agreements on the ITSP side.

No developer-first incumbents. The large Indian telecom operators (Airtel Business, Jio Enterprise) are built for enterprise customers with long contract cycles, not for a developer who wants to spin up a number over a weekend.

The result is that most voice-AI developers building for the Indian market either skip inbound entirely, use SMS fallback, or cobble together offshore numbers with unreliable India routing.

What a clean DID-to-agent connection looks like

The ideal flow for a voice AI agent on an Indian number:

1. Number provisioned and verified (handled by provider)
2. Inbound call arrives at DID
3. Provider fires webhook POST to your URL:
   { "call_id": "...", "from": "+919...", "to": "+9198...", "timestamp": "..." }
4. Your webhook responds with routing instruction:
   { "action": "connect", "destination": "sip:agent@your-livekit-host" }
   -- OR --
   { "action": "connect", "destination": "wss://your-retell-agent" }
5. Media is bridged; your agent handles the conversation
6. Call ends; CDR record available via API

With LiveKit specifically, you would run the LiveKit SIP component pointed at the DID provider's outbound SIP trunk, and use the webhook to trigger agent dispatch. With Vapi or Retell, you configure the inbound SIP URI in their dashboard and the DID provider terminates to it.

The critical insight: the DID provider only needs to answer the call and deliver it to your SIP/webhook endpoint. Your agent framework handles everything after that. The hard part is finding an Indian provider that actually exposes that clean hand-off.

Boni Voice API: the developer path for Indian DIDs

Boni Voice API (boni.one/apis/voice) is built exactly for this gap. It provides dedicated Indian (+91) inbound business numbers with developer-oriented routing.

What the API surface covers:

India DID provisioning (boni.one/apis/voice/india-did): get a +91 number assigned to your account, configured for inbound routing.
Webhook routing: point the number at an HTTP endpoint. Boni fires a webhook on inbound calls so your service decides in real time what happens.
SIP routing: connect to a SIP URI — LiveKit SIP, Asterisk, FreeSWITCH, or a hosted provider like Vapi/Retell.
LiveKit connector (boni.one/apis/voice/livekit): native integration for teams running LiveKit Agents who want to skip the SIP plumbing and go directly to agent dispatch.
Call logs: inbound call records accessible so you can build audit trails or debug routing failures.
Fallback handling: Boni manages what happens when your agent endpoint is unreachable, so callers do not hit dead air.

Pricing starts at Rs 500/month per number — within range for a side project or early-stage SaaS. Onboarding is assisted beta; you get in via WhatsApp (link on the product pages above) so a human helps you through initial setup and KYC, which keeps the provisioning compliant without requiring you to negotiate directly with a telecom operator.

The KYC requirement is not optional — it is the same requirement that makes the number legitimate. Boni handles that layer on your behalf.

Who this is for

Voice AI developers building phone agents targeting Indian users who need a reachable +91 inbound number.
AI agencies deploying customer service or IVR agents for Indian businesses.
SaaS platforms that include phone-channel features and need to provision numbers programmatically for their customers.
n8n / no-code automation builders who want to trigger voice agent flows from inbound Indian calls via webhook.
LiveKit / Vapi / Retell users who have the agent working and just need the Indian number layer sorted.

Getting started

Visit boni.one/apis/voice or directly boni.one/apis/voice/india-did.
Use the WhatsApp CTA on the page to start the assisted onboarding.
Complete number provisioning (KYC handled with Boni's help).
Configure your webhook URL or SIP URI in the Boni dashboard.
Start receiving calls on your +91 number routed to your agent.

If you are on LiveKit, the dedicated connector page at boni.one/apis/voice/livekit covers the specific integration steps.

Getting a legitimate Indian inbound number for a voice agent is genuinely hard today. The problem is not technical — it is the opaque telecom layer sitting between PSTN and your code. Once that layer exposes a clean webhook or SIP hand-off, the rest is standard agent development. That is the gap Boni Voice API is built to close.