Platform integration
API strategy
Native integrations vs partner marketplace: how each model works, when each wins, and how to sequence integration marketplace strategy for SaaS platforms.
Every SaaS platform team eventually hits the same fork in the road. You have a growing list of integrations customers keep asking for. Your engineering team can't build them all. Someone in a leadership meeting says the word "marketplace" and suddenly there are two camps: build everything natively, or open the platform to partners and let them do it.
This piece is for CPOs, Heads of Product, and platform leads trying to decide which model fits. The short version: native integrations win when the integration is core to your product's value proposition. A partner marketplace wins when breadth matters more than depth and you have the platform maturity to support outside developers. Most mature platforms need both, but the sequencing matters — and picking the wrong lead model burns 18 months you don't get back.
Native integrations are ones you build, own, and maintain in-house. Your engineers write the connector code, your product managers scope the feature set, your support team fields the tickets when it breaks. The integration ships as part of your product — it looks and behaves like any other feature, and customers rarely think about who built it.
The operating model is straightforward. Product picks the integration targets, engineering builds against the third-party API, QA tests it, and the whole thing goes through your normal release cycle. Because you own the code, you can guarantee behaviour: consistent error handling, the same auth pattern across every integration, a shared observability stack. When Salesforce ships a breaking change, your team fixes it and pushes an update. Customers don't experience the drift as a partner problem — they experience it as your problem, which is the point.
The cost lives in two places. Building each integration takes real engineering time — in our experience, usually 4 to 12 weeks depending on the surface area. Maintaining them is worse. Each connector needs someone watching for API changes, updating auth flows, absorbing schema drift. We wrote about the compounding cost of this in connector maintenance cost: the integration engineering tax nobody budgets for. At 30+ integrations, most teams are spending more on maintenance than net-new work.
A partner marketplace flips the model. Instead of your team building integrations, you publish a public API and let third-party developers — partners, agencies, and sometimes customers themselves — build integrations on top of your platform. You provide the plumbing: authentication, developer portal, sandbox, documentation, a listings page where end users can discover and install what partners have built. Partners provide the integrations.
The canonical examples are Salesforce AppExchange, HubSpot's app marketplace, and Shopify's app store. Each operated as a primarily native platform for years before opening up to third-party developers at scale — and today most of the integrations customers use on those platforms were built by someone other than the platform vendor.
Running a marketplace is a different discipline from shipping product features. You're building infrastructure for developers you don't employ. That means a properly designed public API (see how to build a partner API), a real developer portal (how to build a developer portal), review and security processes for partner submissions, revenue share arrangements, and a partner success function. The engineering effort shifts from building integrations to building the platform that hosts them.
The upside compounds. Once the marketplace works, integration breadth grows without linear headcount. Partners are motivated to keep their integrations current because their revenue depends on it. And your customers get a discovery surface — one place to find every tool that works with your product — which becomes a real competitive moat.
Build it yourself when the integration is part of the product's core value, not an adjacent nice-to-have. If your CRM's value depends on syncing with a specific email platform, that integration cannot be a partner's problem. It has to work every time, and it has to feel like part of the product. Any inconsistency in behaviour, error messaging, or data mapping will read as your product being broken.
Native wins when you have a small, well-defined set of integration targets. A handful of key partners — the ones your top 20% of customers actually use — is usually 10 to 20 integrations. That number is tractable in-house. It's when you get to 100+ requests that native starts to break down.
Native also wins early. If you don't yet have product-market fit at the platform layer, launching a marketplace is premature optimisation. You need real demand from real developers before a marketplace works, and you need enough active customers that a partner's integration is worth their engineering time. Most teams underestimate this — a marketplace with three listings is worse than no marketplace, because it signals a ghost town.
One more case: when data sensitivity or compliance rules out third-party code touching customer data. Healthcare, finance, and government platforms often can't afford the surface area of partner-built code even with review. Native integrations keep the security perimeter tight.
Open up when integration requests outpace your team's capacity by 3-5x and show no sign of slowing. If your roadmap has 40 integrations queued and product keeps adding more, native will not save you. Marketplace is the only model that scales past headcount.
Marketplace wins when your customer base is diverse enough that no single integration set covers everyone. If you sell to marketing, sales, and operations teams across ten verticals, you cannot possibly ship native integrations for every combination. The marketplace lets each customer segment find the tools that fit their workflow, without you having to prioritise between them.
It also wins when partners have their own commercial incentive to build. Salesforce's marketplace works because being on AppExchange is a real distribution channel — partners will invest six-figure engineering budgets to be listed. If your platform doesn't have that pull yet, partners won't show up, and you'll be running a marketplace with nothing in it. This is why marketplace timing matters so much: you need to be big enough that being on your platform is worth partner investment.
Finally, marketplace wins when discoverability is a competitive advantage. If customers are actively shopping for integrations — comparing platforms based on which tools they support — a marketplace surface is a marketing asset. "400+ integrations" reads differently than "we're working on it."
Both models were designed for human integrators. Someone at the customer clicks "connect," completes an OAuth flow, and uses the integration through the UI. The strategic conversation now is that AI agents are becoming a third consumer — one that doesn't click buttons, doesn't read documentation the same way, and needs a much wider surface than either native integrations or partner marketplaces typically expose.
The rewrite this triggers is the same problem we covered in API products are not the same as agent-ready products. A partner marketplace exposes what partners have built against your public API. A native integration exposes what your product team decided to build. Agents need to reach the other 98% — the internal surface that neither model touches. That's a different problem, and it's the one most platforms will hit next.
Marketplace strategy and native integration strategy both assume the integration surface is small enough to curate. That assumption held when integrations were built for humans clicking through connect flows. It breaks when agents become a consumer, because agents need reach into the full product surface — not the 2% that shipped as a marketplace listing.
Pontil is a Tools-as-a-Service platform. We generate agent-ready tools from the systems SaaS teams already own — the internal APIs, the surface behind the UI, the capabilities that never made it into a public integration. The tools stay current as the product changes, and they execute as the authenticated user, so permissions and audit trails behave the way security review expects. Teams working through marketplace decisions often find the harder question isn't native vs partner — it's how to make the whole product reachable to agents without another two-year rewrite.
If you're under 20 integrations and demand is manageable, stay native. The overhead of running a marketplace isn't worth it, and native gives you the quality bar that early platforms need to build trust.
If you're past 40 integration requests and your team is drowning, open a marketplace — but do it seriously. That means a real public API, a real developer portal, a partner success function, and enough distribution pull that partners will invest. A half-built marketplace is worse than none.
If you're building for agent use cases, both models are the wrong frame. The integration surface most platforms expose today — whether native or partner — is a fraction of what their products can actually do. That's the harder problem, and it deserves a separate answer.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
