Customers don’t only find you on your website. They might tap “contact support” inside your app, ask about loyalty points in your mini program, or stare at an error code on a connected device wondering what it means.
A website widget can’t catch any of that — there’s no website involved. That’s what a custom API channel is for: wiring YundaDesk’s AI support directly into products you built yourself.
What a custom API channel actually does
In plain terms, the custom API channel lets you call YundaDesk’s AI support through an API and surface it inside any interface you own — an app, a mini program, an internal dashboard, even a hardware screen.
A message from your product gets passed to YundaDesk through the API. The AI answers from the knowledge base when it has grounds to; when it can’t, when the customer asks for a human, or when the situation is high-risk, it hands off to an agent. That agent works the conversation in the shared workspace, alongside sessions from the website widget, WhatsApp, email, and every other channel — all landing in one inbox with one customer profile.
Customers don’t notice a system switch. They’re still inside your app asking a question. Your team doesn’t need a separate support backend for every surface you ship.
Use case one: in-app support without leaving the app
A common complaint in cross-border ecommerce apps: tap “contact support” and you either get an external web link or get dumped into an email client. The experience breaks right there.
A custom API lets the in-app chat window talk directly to the AI. High-frequency questions — order status, return policy, shipping timelines — get answered from the knowledge base without leaving the app. Anything that needs human judgment gets handed to an agent with one click, all inside the same screen the customer started on.
Use case two: mini program membership lookups
In mini program contexts, the questions tend to be specific: “How many points do I have,” “when does my tier upgrade,” “why isn’t this coupon working.”
Those answers live in your membership database, not in a static knowledge-base document. A custom API can feed membership data into the conversation context, so the AI answers with the actual customer’s status instead of a generic explanation. Your system still owns the business logic — tier rules, points calculations — the AI just turns that data into a conversation the customer can follow.
Use case three: order tracking, the highest-volume ticket type
Order status questions make up the largest share of tickets for nearly every cross-border seller. “Where’s my package,” “when does this ship,” “can you change the address.”
Piping order data through a custom API means the AI can answer with real order details on any channel, instead of “please provide your order number and an agent will follow up” — a line that slows everyone down. Address changes and refunds still route to a human for approval; the AI doesn’t execute sensitive actions on its own.
Why order tracking is the first custom API use case
Use case four: error codes and prompts on IoT devices
If you sell connected hardware — smart home devices, wearables, electronics with a screen — customers hit error codes they can’t decode on their own.
A custom API lets the device or its companion app call the AI directly, translating an error code into plain instructions and troubleshooting steps. Keep the knowledge base updated with what each code means, and the AI can answer the moment the problem shows up, without waiting for an agent to come online.
Why route it into one workspace instead of a separate system
Teams often start by picking a different support tool for every surface: one for the app, one for the mini program, one for the website. The result is a customer who contacts you through three products and an agent staring at three disconnected records — asking for identity and context all over again each time.
Once a custom API feeds into YundaDesk, it doesn’t matter whether a message comes from the app, the mini program, the website widget, or WhatsApp — it all lands in the same shared workspace, tied to the same cross-border CRM profile via the omnichannel inbox. Country, language, timezone, and social IDs come as standard fields, with matching identities merged automatically. A customer who messages through the app today and follows up by email tomorrow is still one relationship to the agent, not two.
What to settle before you wire up a custom API
- What data actually reaches the AI: read-only fields like order status or membership tier are low-risk. Anything touching payment details or password resets generally shouldn’t sit in the conversation context.
- Who owns the knowledge base: error codes and policy language need someone updating them, or the AI keeps answering off an outdated version.
- Where the hard limits sit: refunds, price changes, and compensation should go through human approval regardless of which entry point the customer used — the AI doesn’t act on those alone.
- What triggers a handoff: the AI can’t answer, the customer asks for a human, or the situation is flagged high-risk — those rules should be explicit, not left to the AI’s judgment alone.
The bottom line
A custom API isn’t about showing off engineering — it’s about meeting customers where they already are: inside your app, your mini program, your device screen, instead of pushing them out to find your website.
The test for whether it’s worth building is simple: if your product itself is already a high-volume support entry point and it isn’t wired into a unified system yet, that’s the gap to close. Start with whichever use case generates the most volume — usually order tracking — get it working, then expand into membership and IoT scenarios from there.
A custom API is just one way in. If you want the fuller picture of what AI support can and can’t handle before it hands off to a human, see what is AI customer service.