Guide
Widget vs API Integration: Which Should Your SaaS Offer?
Short answer: offer a widget when you want small products to put your feature in front of their users this week, and an API when partners need your data inside their own model or their own interface. A widget asks the host to place your feature; an API asks the host to build it again. Most products that get integrated widely end up offering both.
What is the actual difference?
Both let another product use what yours does. The difference is who builds the part the user sees.
- An API integration: you publish endpoints, and the host designs and builds its own screen, handles your auth and your errors, and keeps it working as your API changes.
- A widget integration: you ship the screen, sign-in and checkout included, and the host drops it into its product, usually as an iframe it can theme but not rewrite. What a widget integration is covers the definition.
That one difference moves almost everything else: how fast it goes live, who maintains it, who knows the user and who gets paid.
Widget vs API, side by side
| Widget | API | |
|---|---|---|
| Who builds the UI | The owner, once, for every host | Every host, separately |
| Time to live for the host | Placing, sizing and theming it | A design and build project |
| How much the host can customise | Colours, fonts, spacing, placement | Everything |
| Sign-in and billing | Inside the widget, or through the host's own accounts | The host's problem |
| Who maintains it | Mostly the owner | The host, after every change |
| Who can sell to the end user | The owner, with the host keeping a share | Usually the host, or nobody |
| Works headless or in background jobs | No | Yes |
| Best for | Small host teams, a feature users pay for | Data sync, custom UI, engineering-led partners |
Who builds the interface, and why does it matter so much?
Because building the interface is most of the work, and an API hands that work to every partner. Ten hosts integrating your API means your feature gets designed ten times, by teams who know it less well than you, at ten different quality levels. Most of those teams are two founders with a roadmap of their own. Your integration is the project they will start next quarter.
A widget turns that into a placement decision. The host picks where it goes and passes its colours and fonts, and your feature shows up looking like theirs. If a host can go live in an afternoon instead of a sprint, you get integrated by people who would never have scheduled the sprint. The host side of that is in how to embed a third-party widget.
Who owns the user, the sign-in and the billing?
With an API, the host owns all three. That is right when the host is selling your capability as part of its own plan, and wrong when you need the user to know it's yours, sign up and pay you.
A widget can carry its own sign-in and checkout, so the user can buy your feature inside the host's product without leaving it. On Ordana there are two ways to do that. A host with its own accounts signs the user in with a short-lived token from its server, and can bill its own users and buy their seats at the wholesale price. A host without accounts uses Continue with Ordana: one account and one wallet for the user, and Ordana takes the payment and splits off the host's share automatically.
What breaks more often: a widget or an API integration?
The API integration, from the host's side. Every field you rename and every endpoint you deprecate becomes a ticket in somebody else's backlog, which is why integrations quietly rot after launch. With a widget, you ship a fix and every host has it, because nobody copied your interface into their code. The host's surface area is the embed contract: the URL, a few parameters and a few messages.
A widget doesn't remove the need for discipline, it moves it. You still version what hosts depend on, and you still give notice before a change that affects them. On Ordana an owner's commercial terms are immutable versions, and changing the price, free uses or host share comes with 30 days' notice to every host already using the widget.
When does an API win?
- The host needs the data, not the screen. Syncing records into its own model, reporting on them, joining them with its own.
- It has to run headless. A background job, a scheduled export, an agent calling your capability with nobody watching.
- The host wants its own interface, for a reason you should respect: the feature sits inside a flow they've designed to the pixel.
- Your partners are engineering-led and would rather own the code than embed yours.
If that describes most of the people asking, publish the API first and package it properly. How to package your API for integration partners is the checklist.
When does a widget win?
- Your hosts are small. A team without spare engineering will place a widget and never build against an API.
- The value is in the experience. A capability whose interface is the product, not a thin layer over data.
- You need to sell it to the end user. A widget can carry the sign-up, the free uses and the checkout. An API can't.
- Every use costs you money. An AI feature, a paid data lookup, anything with a real cost per call. With a widget, your server asks before each use whether this user may run it, so free uses are capped per host and one busy host can't run up your bill.
Why offer both?
Because your hosts aren't one kind of company. The two-person startup wants the widget; the partner with a platform team wants the endpoints; plenty want the widget now and the API later. Offering both costs you less than it sounds, because they share the same capability underneath.
That's how a widget on Ordana is shaped. Every widget has a data face, an integration manifest that says how auth works, which calls a host may use and how much notice comes before a breaking change, plus optional public API documentation written by the owner's own coding agent from the code. It can also have a UI face, the embeddable widget itself, which a host mounts as a card, a full page or a modal. Hosts take the screen, the endpoints or both.
If you're starting from nothing, build the widget first. It's the version a small host can say yes to this week, and every host that embeds it is a user base you can sell to without buying a single ad. The steps are in how to build an embeddable widget, and the commercial side in how to price one.
Frequently asked questions
What is the difference between a widget and an SDK?
An SDK is code the host installs and builds with, so the host still builds the screen, as with an API, just with less plumbing. A widget is the finished screen. Pick an SDK when the host wants its own interface with less work than a raw API, and a widget when the host wants the feature itself.
What is the difference between a widget and an API integration?
With a widget, the owner ships the screen and the host drops it into its product, usually as an iframe. With an API integration, the host builds its own screen and calls the owner's endpoints. A widget is faster to go live and keeps maintenance with the owner; an API gives the host full control and full upkeep.
Is an embedded widget faster to integrate than an API?
Almost always. A host embeds a widget by placing it, sizing it and passing a few theme settings, because the owner already built the interface, the sign-in and the checkout. An API integration means designing and building that interface, handling errors and auth, and maintaining it every time the owner's API changes.
When should a SaaS offer an API instead of a widget?
When hosts need the data more than the screen: syncing records into their own model, running your capability headless in a background job, or building a deeply custom interface. Offer an API when your partners have engineers who want control and will maintain what they build.
Can I offer both a widget and an API?
Yes, and most products that get integrated widely end up doing both. On Ordana every widget has a data face, the integration manifest and optional public API documentation written by the owner's own coding agent, and an optional UI face, the embeddable iframe. Hosts choose the screen, the endpoints or both.
How do you charge for a widget compared with an API?
An API is usually billed to the host company by volume. A widget can be sold to the end user directly, inside the host's product, with the host keeping a share. On Ordana the owner sets the price, the free uses and the host's share between 10% and 90%, and Ordana's fee is 10% of each sale, taken from the owner's share.
On Ordana, a startup lists a feature as a widget, with its API documentation beside it, and other startups add it to their products with no application and no approval. List your SaaS as a widget, or browse the widgets worth adding to yours.
Related reading:
- Widget Integrations — every guide in this series.
- How to Sell a SaaS Feature as a Widget — packaging and listing one.
- How to Embed a Third-Party Widget in Your SaaS — the host's side.
- Build vs Buy for SaaS Features — the question underneath both.