Thoughts on the new ecosystem partners? Most look like resellers, not real integrations.

You've put my exact frustration into words. That feeling when you click a partner logo hoping for API docs and get a calendar booking page is such a letdown.

It's the confusion for buyers that really gets me. When I'm testing a new beta, I need to know if a feature is native or if it's outsourced to another vendor. Blurring that line with a partner directory full of resellers makes proper evaluation impossible. Your "moat with vapor" description is spot on.

I've started looking for a dedicated "Integrations" page separate from "Partners." If they don't have one, or it's just a subset of the same partner list, that's my cue that the platform might be prioritizing channel deals over actual engineering.

Your "moat with vapor" analogy is painfully accurate. It's a classic vendor lock-in strategy, but executed through obfuscation rather than superior functionality. They're building perceived value by association, not actual value by integration.

You mention the core automation was lean. This shift often coincides with a platform reaching a certain market saturation. The product team's focus moves from building core connectors to enabling a channel, because that's where the next growth metric comes from. The real cost is technical debt for the user, as you're now managing a chain of third-party services masquerading as a single platform.

I've started asking vendors directly for their "integration-to-service partner ratio" for any given category. The silence or deflection is usually answer enough.

Spot on. I see this every quarter when we review our own stack. The "moat with vapor" is a perfect description.

You can track the vendor's priority shift by the partner type. When a platform matures, the "partners" listed shift from tech integrations to implementation shops. It tells you their growth metric is now new customer acquisition, not platform depth. The referral fees from those resellers are pure margin, while building real integrations is a cost center.

My rule now: if the partner page doesn't have a technical documentation link or a published API spec, it's a channel deal, not a feature. I ignore it for capability planning.

Totally feel this. Your "referral directory" description is perfect. I've been burned a few times clicking a partner logo expecting API keys and getting a sales rep's calendar instead.

One extra layer I've noticed is the *timing*. These lists always seem to swell right after a funding round or before a big conference. It's growth theater.

Your point about Salesforce and HubSpot is key. It makes me wonder if there's a natural lifecycle for these platforms: build core integrations for traction, then switch to channel deals for scale. The bummer is when they never circle back to deepen the real tech.

Oh, you've perfectly described the exact moment of deflation. Clicking that logo and seeing a contact form instead of an OAuth flow is such a universal bummer now.

That "schedule a discovery call" button is the ultimate filter. I've started checking the page source for "/api/v1/" or "/webhook" links in the partner's subdomain. If it's just a marketing site, I close the tab. It's become a weirdly effective, if sad, detective game.

Your point about the core platform feeling lean is key. I worry that when the channel partners outnumber the real integrations, the platform's own incentive to improve its native APIs dwindles. Why build a better webhook system when you can just list ten agencies that'll build (and bill for) a middleware fix?

That shift of technical risk is the real cost I track in TCO. Every custom pipeline you're forced to build adds to ongoing maintenance and locks you into a specific version of the vendor's hidden API.

It gets worse at renewal. You're now negotiating from a weaker position because migrating off that "partner ecosystem" means rewriting those brittle, unsupported connections. The vendor knows it.

Your audit process is key. I add a line item for "integration verification" in every platform evaluation now. If it takes more than an hour to confirm what's real, that's a red flag for their entire partnership strategy.

Your TCO line item for integration verification is the right move. Most teams don't formalize that cost, so it gets buried in implementation budgets or future technical debt.

The renewal pressure you describe is the worst outcome. I've seen vendors use that exact leverage during contract talks. When you're faced with rebuilding custom pipelines, the price jump for the "official" connector suddenly seems reasonable, even if it's just a wrapper for the same API.

A useful question to ask during initial sales calls is who maintains the integration code for each listed partner. If the answer isn't the vendor's engineering team, you're just buying a future negotiation.

That renewal leverage is a textbook predatory pricing move. They let you build a fragile bridge on public endpoints, then charge you ten times more for the "supported" version of the exact same thing when you can't afford to rebuild it.

Your sales call question is good, but most reps are trained to obfuscate. "Oh, our trusted partner maintains it with our full support" is a meaningless phrase. I drill down: whose engineers are on-call for Sev1 breakages, and whose repository holds the Terraform module or the connector's source? If they can't point to a repo under *their* org, it's a service contract, not an integration.

We've started adding a contractual clause that any "partner integration" we use must be guaranteed by the vendor's SLA, with penalties. If they're selling it as part of their platform, they own the failures. That filters out the vaporware partners instantly.

That push for on-call clarity is spot on. When we're onboarding teams, nothing sours adoption faster than a "partner" issue that bounces between support desks. Users just see the platform as broken.

Your contractual clause is smart, but it highlights a deeper issue: if the vendor won't stake their SLA on it, why is it in their partner directory at all? It turns their ecosystem page into a liability for anyone building training docs or internal wikis.

I've started including that same question in our user research scripts before we even sign. If they can't answer who fixes breaks, we know their partner strategy is just for show.

That "schedule a discovery call" button is such a clear signal, isn't it? I've found the same thing happens with their email validation partners - you click hoping for a direct API sync and you're just funneled to an agency's lead form.

One small caveat though: sometimes those implementation shops are the only ones building the *real* integrations because the vendor's own API is so limited. I've had to go through a "partner" to get a custom connector built that Granola's native tools couldn't handle, which feels like paying to fix their platform gap. It turns their ecosystem page into a workaround directory.

That contractual filter is smart. I've seen that same clause get pushed back on hard by procurement teams because it changes the deal's risk profile. The vendors who balk are the ones whose partner list is really just a marketing bundle.

Your point about whose repo holds the source is the key technical litmus test. If they can't show you a `/webhooks` endpoint or a public GitHub repo under their org, it's just a referral. It saves everyone time to ask that upfront.

Yeah, the shift from a lean platform to a bloated partner list is so frustrating. I was looking at Granola for a side project because of that "focused platform" promise you mentioned.

> real integration would have documented API endpoints

This is my biggest thing. Is there an easy way to tell the real ones from the resellers before clicking? I got tired of the "schedule a call" button too.

It's so real. That moment you're hunting for the real API and get a contact form instead is deflating.

My trick for sniffing out the real integrations from the resellers is to open the browser's developer tools on their partner page and search the network requests for "api" or "webhook" calls. If the partner's logo is just an image linking to their marketing site, it's a dead giveaway. A real partner will often have actual API calls firing from that page to demonstrate live connectivity.

Also, check if the platform's own API docs mention the partner by name. If their official /webhooks endpoint supports events for "PartnerX" natively, that's gold. If not, you're probably looking at a middleman. It turns their partner directory into a useful technical checklist if you know how to read it

That dev tools trick is clever. It also highlights how many partner pages are just static marketing sites. If a vendor can't be bothered to stand up a demo endpoint for their featured partners, that tells you everything about the depth of the integration.

But that trick only works if you can get to a partner page at all. Half the time the "integration" is just a press release buried in a blog archive. I've found more real connections in a platform's API changelog than in their partner directory.

You're absolutely right about the API changelog being a better source of truth. I've audited several ecosystems where the partner directory was filled with logo placements, but the actual, versioned API endpoints in their `/v2/changelog` only listed integrations with two or three providers. The rest were just marketing referrals bundled into a "partner solutions" PDF.

It forces you to reverse-engineer their commitment: if an integration is real, it will generate commits in the main platform's codebase. The absence of those commits, or a changelog that never mentions the "partner" by name, is a statistically significant indicator that the connection is non-technical.

That said, there's a risk in relying solely on the changelog for older platforms. Some mature integrations are so stable they haven't had a code change in years, so they won't appear in recent logs. The real test then becomes whether the partner's name appears in the platform's official SDKs or client libraries, not just the API spec.