How to Get Other SaaS Products to Integrate Yours

Short answer: stop asking other products for "an integration" and offer them a finished thing: one feature packaged as a widget, a prompt their coding agent can run, a preview they can click, and terms written down before you ask, including the share of every sale they keep. Then ask the products whose users already reach the step your feature solves, with one link they can act on.

Why do most integration requests go nowhere?

Look at the request from the other side. You're asking a founder to spend engineering time on your feature, put it in front of their users, answer the support tickets when it misbehaves, and keep it working every time your API changes. In return, the usual offer is a launch post and a logo on each other's integrations page.

That isn't an accident of your outreach. It's how integration partnerships normally work: a referral partner who sends one email typically earns a share of first-year revenue, a reseller earns a share of ongoing revenue, and the integration partner who writes software that lives inside another company's product usually earns nothing. We went through the numbers in integration partnerships that share revenue.

So the request competes for a day of the host's engineering against roadmap items that have a revenue number next to them. Yours doesn't. It loses, politely, every time. Better copy won't fix that. A different offer will.

What does a host need before saying yes?

Four things, and most requests offer none of them.

1. It has to be cheap to build. Not "our API is documented", which hands them a project. One feature, packaged so it drops in, with a prompt their own coding agent runs in their own codebase. The ask shrinks from a sprint to an afternoon.
2. They have to see it first. A clickable preview of the feature, working, beats any description. Founders argue about things they can point at; they ignore things they have to imagine.
3. It can't break their product. It has to fit their screens (a card, a full page or a modal from their own button), take their colours and fonts, and stay out of their code. A widget that runs in its own frame and only talks to the page through a few documented messages is far easier to say yes to than a library that reaches into their app.
4. It has to pay them. A share of every sale made through their product, paid out automatically, on terms they can read before adding it and that can't change under them without notice. That turns your feature from a favour into something they sell.

Doing the packaging well is its own job; we walk through it in how to sell a SaaS feature as a widget. The rest of this post is about who to ask and how. If you're unsure what share to offer, the maths is in how to price an embeddable widget.

Which products should you ask?

Not the biggest ones, and not the ones in your category. The rule we use is same customer, same job, different step. The host serves the people you want, for the job you also help with, but it handles a different part of that job, so your feature is the obvious next thing their users reach for.

A fictional example: a booking tool for independent yoga studios. Its users take bookings all day, and every new client has to sign a waiver before the first class. A waiver-signing widget is the next step of the same job, inside the screen where the booking happens. The same widget inside a general-purpose CRM is just another menu item nobody opens.

Before you ask a product, check three things:

• Do its users hit your step without leaving? If they'd have to go somewhere else to need you, the widget sits in the wrong place.
• Can it sell your feature as part of its own? The host's share only matters if the feature makes sense to its users at its price point.
• Is it small enough to decide in a week? A founder who owns the roadmap can say yes in one conversation. A partnerships team needs a quarter.

The longer version of this filter is in how to choose an integration partner.

How should you ask?

With one link they can act on, written about their users rather than about you. Every widget listed on Ordana gets its own public page: what the widget does, who it's for, the price, the free uses and the share the host keeps. Any founder who opens it can add the widget to their product from there. That page is your whole pitch, so the message around it can be three sentences:

• what their users are doing when they'd need your feature,
• what the host keeps from each sale,
• and the link.

One product per message. A message that could have gone to fifty founders reads like it did. And put the widget's badge on your own site, next to your pricing or your integrations page, so the products you didn't think of can find you: every listed widget gets a small badge that reads "Add" followed by your startup's name and "to your product", and opens the widget's page.

Keep the framing honest. You aren't asking them to point their users at you; you're offering them something new to sell inside their own product. That's a different conversation, and it's why a widget converts better than a link: in our own case, 32% of the founders who clicked through signed up while our offer lived inside a partner's product, against 7% once it became one link among several (the full story).

How does Ordana help hosts find your widget?

Three ways, on top of your own asking.

• The directory. A listed widget appears in Ordana's widget directory and in the matching Ordana runs for founders looking for a capability to add.
• Find products for your widget. Ordana's AI reads your widget and your product and picks startups on Ordana whose users would use it, each with its reasoning. Searching is free; invitations are capped at 5 per 30 days, so you choose who to invite with the number in view. Holding a bounty balance of €500 or more lifts the cap, because then an invitation carries a paid trial instead of a request.
• Bounties. A paid trial for each new product. You fund a budget, set a price per 100 users, a trial length of 30, 60 or 90 days and a maximum number of users per product. Products apply and you approve the ones you want, or you let every new product in. When an approved product's integration goes live, its trial starts and its money is reserved, so it is paid in full even if your budget later runs out. Ordana keeps 10% of the price. After the trial, the product earns through its share of sales.

When is a widget the wrong answer?

Be honest with yourself here, because a host will be. A widget needs a feature that can stand on its own inside someone else's product: it takes an input, does something useful and shows a result. If your value only makes sense across your whole product, start by finding the one piece that doesn't, or accept that your integrations will look more like data syncs than widgets.

Big platforms are a different game too. If you want to be inside a large product that runs its own app marketplace, follow its program and its review; nobody there is going to add a widget because a founder emailed. This playbook is for products of similar size that serve the same customer, where one founder can say yes.

And one host is not a channel. The first integration teaches you what hosts ask, what breaks and what the right share is. The channel is the tenth, which is why the packaging and the terms have to be done once, properly, rather than negotiated per deal. If you're still building the list, start with how to find integration partners.

Frequently asked questions

On Ordana, your coding agent packages the feature, you confirm the price, free uses and the host's share, and you get a widget page any founder can add your widget from. Ordana runs the sign-up and checkout inside the widget and splits every sale automatically. List your SaaS as a widget, or read the rest of the widget integration guides.

Related reading:

• What Is a Widget Integration? — the definition, and why it beats a link.
• How to Embed a Third-Party Widget in Your SaaS — what the host's side of the work looks like.
• Embeddable Widget Examples — widgets other products already embed, and what they get right.