TL;DR: Integrations are now a top-three buying criterion. You don’t win by having APIs—you win by making integrations easy to find, adopt, and operate. This post breaks down four practical build paths, a simple decision matrix, the infrastructure you actually need for an open ecosystem, and a real-world example from G2.
Why integrations matter more than ever
For most B2B buyers, 69% of the journey happens before they talk to sales. They ask peers, scan review sites like G2, and check whether your product fits their stack. “Does it integrate?” is a top consideration—often outranking features for SMB/mid-market and sitting right behind security for enterprise.
Integrations don’t just open doors for new deals; they also keep customers. In the webinar session this post is based on, we cited data showing customers with even one integration renew at materially higher rates; install four or more and renewal probability jumps dramatically.
The punchline: integrations drive pipeline and retention.
Watch the full session with Kenny & Riley
Four ways to launch integrations
Anyone who has worked with integrations knows there isn’t one “right” approach. Most successful teams start by building each from scratch, then move through the various other methods, usually landing on a mixed approach.
It just makes sense to spend more time building and maintaining high value integrations, and finding another path to deliver integrations only requested by a few customers.
1) Build in-house
Best for: Your most strategic, high-demand, high-value connections (e.g., your CRM or core data hub).
Pros: Deep control, best UX, fastest issue resolution, clear ownership.
Cons: Expensive to build/maintain; creates engineering bottlenecks; every integration is a trade-off against core roadmap. Even with two full-time engineers, many teams top out at single-digit net new integrations per year.
2) iPaaS (integration platform as a service)
Best for: Medium-value connections where speed and coverage matter more than depth.
Pros: Faster time-to-market, broad catalog, lighter engineering lift.
Cons: Often shallow; still requires ongoing product/eng involvement for quality; real-world adoption can be lower than sales decks promise. Treat it as a tool in your belt, not “the whole belt.”
3) Unified APIs
Best for: Categories where many targets share similar models (e.g., HRIS, ATS, CRM variants).
Pros: One build → many destinations; simplifies maintenance.
Cons: Middle-layer data modeling and storage introduce trade-offs; you’ll still customize for edge cases and top partners.
4) Open ecosystem (partners and customers build)
Best for: Long-tail coverage and category expansion once you’ve proven demand.
Pros: Scales breadth without linear engineering cost; can create a flywheel of partners → value → customers → more partners.
Cons: “If you build it, they’ll come” is a myth. You need real infrastructure, program design, and GTM to incentivize third-party developers to build on your APIs.
A simple decision matrix
When choosing how to build a specific integration, map it on two axes: customer demand and value/strategic importance.
- High demand / high value: Build in-house. Own the experience end-to-end (think: your HubSpot/Salesforce integration).
- High demand / medium value or medium demand / medium value: iPaaS or unified API can accelerate coverage while keeping quality “good enough.”
- Low demand / low to medium value (for you): Open ecosystem. It might be high value for a partner—let them build and maintain it with your support.
This sounds simple, but it works—and it keeps engineering focused where it matters most.
What an open ecosystem really requires
Publishing API docs is not the same as operating an ecosystem. If you want partners to build (and customers to adopt) at scale, you’ll need:
- Developer portal: Self-serve org creation, API tokens/OAuth, onboarding guides, code samples, and sandbox data. No tickets or back-and-forth to get started.
- Submission & review: A structured flow for app submission, legal terms, security/compliance checks, and QA.
- Discovery: A public marketplace for prospects and an in-app integrations page for customers. If buyers can’t find it, it doesn’t exist.
- Operations & analytics: Visibility into installs, attach rates, active usage, partner performance, and customer outcomes.
- Program & GTM: Clear program tiers/benefits, co-marketing motions, and ongoing enablement so partners see value and stick around.
Treat this like a product, not a side project. The top ecosystems (HubSpot, Shopify, Slack) invest in all five.
A quick case study: how G2 moved from APIs to self-serve
G2 had successful partnerships, but onboarding was manual: request a token, wait for docs, coordinate with internal teams. To remove friction, the team built a self-service developer portal so partners could create orgs, generate API keys, spin up OAuth apps, and start testing immediately—including access to sandbox data for real use cases like buyer intent and market intel.
Key lessons from their journey:
- Make it company-level. This wasn’t “just a product task.” Partnerships, product, security, and legal aligned on a shared objective: faster partner time-to-integration.
- Invest in ease of use. Clear onboarding docs, code examples in multiple languages, and intuitive flows matter more than you think.
- Don’t reinvent every wheel. They initially tried to build internal partner-application workflows, then tapped Partner Fleet to handle submissions, reviews, and marketplace listing so their team could focus on data, APIs, and developer experience.
- Plan for scale. Monitoring partner-built integrations and maintaining quality at scale is its own muscle. Build processes (and pick platforms) that make this repeatable.
The ecosystem flywheel (and why sequencing matters)
Most companies follow a repeatable pattern:
- Seed demand: Build a set of flagship, high-value integrations in-house (and/or via iPaaS/unified API).
- Open the gates: Publish polished docs and a dev portal; invite partners to build.
- Productize the program: Launch submission/review, marketplace listings, and co-marketing.
- Scale with data: Use analytics to double down on what drives attach, adoption, and retention.
Slack famously built dozens of integrations before opening up. Once partner-led building kicked in, they jumped from dozens to hundreds—and then thousands—because the flywheel took over.
Common pitfalls to avoid
- Counting “API docs live” as done. Success is installs and active usage, not page views on your docs.
- Over-outsourcing critical flows. Own your crown-jewel integrations.
- Skipping legal/security. One leaked key can become a company-level incident.
- No analytics. If you can’t measure attach and adoption, you can’t improve them—or defend the program to leadership.
The bottom line
APIs are table stakes. The winners make integrations easy to find, adopt, and operate—for humans and, increasingly, for AI-driven buyers. Pick the right build path per integration, invest in the ecosystem infrastructure, and you’ll compound value on both the sales and retention sides of the house.
