APIs Are Not Enough: The Case for Embeddable AI

ThoughtSpot’s Ashish Shubham offers commentary on why APIs are not enough and provides the case for embeddable AI. This article originally appeared in Insight Jam, an enterprise IT community that enables human conversation on AI.

The AI industry has inherited a familiar playbook from the developer tools era: ship an API, write documentation, let developers build. This approach conflates access with distribution. An API gives developers access to capability, but it doesn’t help them ship products.

After years of building embedded analytics at ThoughtSpot, I’ve come to believe that for AI products with user-facing surfaces, APIs alone are insufficient. If you want developers to actually adopt and retain your product, you need to ship embeddable UI alongside your endpoints.

The Real Cost of “Just Use Our API”

Consider what happens when a developer integrates an AI-powered capability via API. They get the core intelligence (the model output, the prediction, the recommendation). But then they’re on their own for everything else: input collection, result presentation, error handling, loading states, edge cases, accessibility, localization.

Think about an AI-powered airline booking experience. The API might return flight options ranked by some intelligent criteria. But the developer still needs to build interfaces for: how many travelers, what class, number of stops, departure and arrival time preferences, airline filters, and then how to actually display the results in a way users can compare and act on. Every team rebuilding this from scratch is duplicating effort, and likely doing it worse than a dedicated team would.

This isn’t hypothetical. The pattern is proven in adjacent domains.

Stripe didn’t become ubiquitous because of their payments API. Stripe Checkout, the embeddable UI, is what made integration trivial. It handles 3D Secure, card brand detection, address validation, error states, localization, accessibility. You’re not just saving time; you’re getting accumulated expertise you’d never build yourself.

Google Maps and YouTube embeds are so prevalent that most people interact with these products through third-party sites, not directly. The embed is the product for most consumers.

Plaid’s Link component is what made Plaid ubiquitous in fintech, not the API underneath it. The UI encapsulates the complexity of connecting to thousands of financial institutions with different authentication flows.

The Framework: Embeddable UI = API + Expertise + Time-to-Value

I’m not arguing against APIs. They should exist. But embeddable UI should be layered on top, capturing three things APIs cannot:

• Expertise: Every user-facing surface has edge cases that only become apparent after thousands of implementations. An embeddable component encapsulates lessons learned — the error states you didn’t anticipate, the accessibility requirements you’d miss, the interaction patterns users actually expect.
• Time-to-Value: A developer evaluating your product wants to see it working in their application as quickly as possible. “Drop in this component” beats “build a UI on top of our API” every time. Faster integration means faster adoption.
• Stickiness: Once developers have built around your embedded components — styled them to match their app, wired up event handlers, integrated with their analytics — switching costs increase substantially. This isn’t lock-in through limitation; it’s retention through genuine integration depth.

Escape Hatches: Control Without Restriction

The skeptical developer’s objection is predictable: “I want full control. Embeds are too constrained.” This is valid, but only if the embed is poorly designed.

A well-built embed SDK balances convenience with flexibility through layered escape hatches:

• Styling: CSS variables for colors, fonts, and spacing are table stakes. But you can’t variablize everything. The escape hatch: allow injection of arbitrary CSS into the embed. The developer gets full control over visual presentation when the standard knobs aren’t enough.
• Events: Expose interception hooks for all significant events, including errors. Let developers show their own error messaging, trigger their own analytics, or modify behavior based on user actions. One example from ThoughtSpot Embedded: developers can inject custom JavaScript to send metrics to their Pendo or Amplitude accounts from within the iframe.
• Extensibility: Allow developers to add their own UI elements that integrate with your product’s context. At ThoughtSpot, we built “custom actions” — developers can add menu items anywhere in the product. When clicked, a callback fires with relevant context, letting them send data to other systems, trigger workflows, or extend functionality we never anticipated.

The principle: developers should feel empowered to do more in less time, not restricted by your component’s boundaries.

What’s the Catch?

Building an embeddable UI is harder than building an API. You’re maintaining a UI contract, not just a data contract. Here’s what you’re signing up for:

• Higher Quality Bar: When customers depend on your embed for core functionality, performance cannot be subpar relative to their own application. Latency that’s acceptable in a standalone product becomes unacceptable when it’s visibly slower than the surrounding app.
• Versioning Complexity: CSS injection and deep customization create implicit dependencies. If your internal CSS changes, customer customizations can break. Even pure UI changes sometimes need to be behind feature flags, controlled by your customer, because they may not be ready to roll changes out to their users.
• Authentication Integration: Users cannot authenticate twice, once to the host application and again to your embed. You need to build token-based trusted authentication where the host provisions and authenticates users on your behalf, with the SDK managing token refresh transparently. Third-party cookies are now blocked by default in Safari and increasingly elsewhere, so cookieless approaches are essential.
• Multi-Tenant Isolation: Security becomes layered: your customer’s users must never see artifacts belonging to another customer’s users. Standard web security controls for clickjacking and related attacks need to work correctly in the embedded context.

These challenges are real. But the distribution leverage (developers who can integrate in hours instead of weeks, who build deeply around your product, who become genuinely dependent on your capability) is worth it.

The Agentic Future: Embeds as Output Primitives

Here’s where this gets forward-looking: even in agentic contexts, embeddable UI matters.

The current generation of AI agents communicates through text. An agent that books flights returns JSON or natural language descriptions. But presentation of information shouldn’t be bound by static text.

Imagine an agent that returns a rendered, interactive flight comparison component instead of a list of options. The user can filter, sort, and select without further prompting. The embed becomes an output primitive, a way for agents to provide rich, interactive responses.

Model Context Protocol (MCP) and similar frameworks are making tool use standardized across AI systems. The next evolution is standardizing output rendering. An MCP server that returns an iframe with a fully functional interface is more useful than one returning data the consuming application must transform and display.

Conversational interfaces are powerful, but they’re not sufficient for every interaction. The mouse was invented after the keyboard for a reason. When agents need to collect structured input or present complex output, embeddable UI components become the bridge between conversational AI and effective user interaction.

What Good Looks Like: Evaluating Embeddable AI

Whether you’re building an embeddable product or evaluating one to adopt, here’s what separates good from mediocre:

• Styling Depth: Can you match your brand completely? Look for CSS variables at minimum, with custom CSS injection as an escape hatch. The embed should be able to disappear visually into your application.
• Event Coverage: Does the SDK expose hooks for all meaningful user interactions, including errors? Can you intercept events before they’re handled, or only react after? The more control over the event lifecycle, the better the integration possibilities.
• Authentication Flexibility: Does it support token-based authentication that integrates with your existing identity provider? Does it work without third-party cookies? The best solutions handle token refresh transparently so developers don’t manage session state manually.
• Extensibility Patterns: Can you add your own UI elements that feel native to the embedded experience? Can you inject custom JavaScript for analytics or behavioral modifications? These escape hatches matter when you hit edge cases.
• Versioning and Stability: How does the vendor handle breaking changes? Is there a deprecation policy? Can you pin to specific versions? When your product depends on their embed, their release process becomes your concern.
• Documentation Quality: Are the escape hatches documented, or do you discover them through support tickets? Good embedded products document not just the happy path but the edge cases and workarounds.
• Performance Characteristics: What’s the load time? How does it behave under poor network conditions? Can it be lazy-loaded? An embed that slows down your application will get ripped out.

For builders, this list is your roadmap. For buyers, it’s your evaluation checklist.

The Call to Action

If you’re building an AI product, ask yourself: does this have a user-facing surface? Does that surface involve interaction complexity beyond displaying a single value?

If yes, embeddable UI should be on your roadmap from day one, not a v2 afterthought. And even if your current customers aren’t developers, consider this: opening up your product as embeddable components creates an entirely new line of business. You’ve already built a capable, polished user experience. Why not let other developers leverage it? The API gets you access. The embed gets you distribution.