7 Common SaaS Integration Problems (and How to Fix Each)

Short answer: the seven problems that sour SaaS partner integrations are credential upkeep, repeated webhook deliveries, silent schema drift, the partner's outage landing in your inbox, attribution disputes, nothing in writing on support and exit, and partner-sourced users churning faster. Only the first three are code problems; the other four are agreements nobody wrote down. Fix the code with a handful of defensive patterns, and fix the rest on paper before launch.

Building an integration got cheap. A coding agent will write a connector between two APIs in an afternoon, and nobody we have heard from complains that the build was the hard part. What did not get cheap is everything after it: maintaining the glue, coordinating two companies when it breaks, trusting each other's numbers, and undoing it when it doesn't work out.

What founders who built one actually say

When we wrote publicly about cross-integrations, three founders who had built one without any platform replied with what it cost them. Their words make the case better than ours.

"Cross-integrations look free until the other APIs start breaking your glue. I shipped a two-way sync once and most of the work was token refresh, idempotent webhooks, and mapping fields that both sides rename without warning."

— a founder who had built one

"rev-share is great until their API goes down and suddenly you're the one getting the angry emails, ask me how I know"

— a founder on a SaaS forum

"The part I'd sort out before the second deal is attribution, because rev-share only stays friendly while both sides trust the numbers. A unique signup link or a partner ID passed through the widget, plus a simple shared monthly report, saves you the awkward conversation where your dashboard says 40 and theirs says 12."

— a founder who had built one

Between them, those replies name all seven problems:

1. Why do integration tokens keep expiring? (Credential upkeep)

Access tokens expire and must be refreshed — per customer, forever. The failure isn't the refresh itself; it's twenty parallel calls each noticing an expired token and triggering twenty refreshes, or a refresh failing silently until a customer reports the feature is dead. The worst version is a call made with the wrong customer's token.

The fix:

• Allow one refresh at a time per tenant (a lock), so concurrent calls wait for it.
• Refresh early — at roughly 80% of the token's lifetime — rather than waiting for a 401.
• Key the token cache by tenant, and assert the tenant id on every outbound call.
• Keep secrets in a secrets manager, never in application tables or logs.
• Count refresh failures and alert on them, so you hear before your customer does.

2. How do you handle duplicate webhooks? (Repeated deliveries)

Webhooks arrive twice. Sometimes they arrive every minute for a day, because the sender retries until it gets a response it likes. Any handler that inserts a row, sends an email or charges a card on receipt will eventually do it twice.

The fix:

• Upsert on the partner's own ids, never insert. The same event processed twice should land on the same row.
• Record processed delivery ids with a time limit and skip repeats.
• Treat unsigned webhooks as a nudge, not as data: on receipt, re-read the current state from the partner's API. If the partner has no "changes since" cursor, keep your own high-water mark per tenant.
• Send an idempotency key on every write you make to them.
• Run the replay test: every delivery sent three times, out of order, and after a restart must leave the state unchanged. If your coding agent wrote the handler, have it write this test too.

3. Why do integrations break when a partner changes their API? (Silent schema drift)

Either side renames a field without warning, and the glue breaks. Usually you find out when a customer does — and by then the bug report says "your product is broken", not "field customer_ref is now account_id".

The fix:

• A tolerant reader. Keep every one of the partner's field names in one adapter file. Validate responses at that boundary. A missing or renamed field should degrade the feature and log the field name — never the value — instead of crashing. Drift is then caught on the first failing call, with the exact field named.
• A notice period in writing. Agree how far ahead either side announces a breaking change, and to whom. A clause doesn't detect anything, but it turns "they broke us" into "they owed us notice".
• Contract tests once a provider has several integrators. Each integrator writes a small spec of exactly the calls and fields it depends on, and the provider runs all of them before each deploy — the consumer-driven contract testing pattern.
• As a fallback, diff the partner's public API docs weekly.

4. Who gets the angry emails when a partner's API goes down?

You do, if the feature lives in your UI. The customer only sees your product; they have never heard of the partner whose capability is embedded in it. This is the problem that turns a friendly partnership into a founder-to-founder argument in a single afternoon.

The fix:

• Write the support split down before launch. Whoever's UI the customer sees owns tier-1. The provider owns tier-2, with a response time you both sign up to, a duty to tell you about incidents, and a role address (never one person's inbox) for escalations.
• Build a degraded mode. Every partner-powered surface gets a branded "temporarily unavailable" state and a circuit breaker: after a few consecutive failures, stop calling and show the state instead of an error. Customers rarely email about a clear "back shortly"; they always email about a broken screen.
• Put the surface behind a flag you control, so hiding it is a decision, not a deploy.
• Subscribe to the partner's status page. Most status-page tools push incident webhooks, so your degraded mode can switch on before the first ticket arrives.

5. How do you avoid revenue-share attribution disputes?

Your dashboard says 40, theirs says 12. Neither of you is lying; you're counting different things from different ends of the funnel. Revenue sharing stays friendly only while both sides trust the same number.

The fix:

• Attribute at the source. Carry a partner ID through the signup, or tag the charge itself, so a sale is attributed once, when it happens, rather than reconstructed later from two analytics tools.
• One monthly statement, confirmed by both. Each side either agrees or disputes a specific line. A disputed line is a conversation; two dashboards are a fight.
• Ask the other side for one number, not a data feed: their monthly count of the customers or units the statement depends on. Two independent sources are enough to catch a disagreement early.
• Agree the dispute process in advance — negotiation first, then a neutral step — so nobody is inventing it while angry.

We go deeper on the money mechanics in why integration partners get paid nothing, and why integrations rot.

6. What should an integration partnership say about support and exit?

Usually nothing, which is the problem. A host partner can pull the embed overnight and take a chunk of the provider's signups with it; a provider can deprecate the endpoint and leave the host with a dead feature. Neither is malicious — there simply was no agreed way out.

The fix: a few lines, agreed before anyone builds:

• Notice in both directions before either side ends the partnership.
• A wind-down: the surface degrades gracefully instead of vanishing mid-session.
• Revenue shares already earned stay payable after the end.
• What happens to customers already using the integration, and who tells them.
• Optionally, a pre-agreed message offering affected customers the chance to continue with the provider directly — opt-in by the customer, never a handed-over list. Treat this as something to negotiate, not a default; hosts can read it as poaching.

One question surfaces the exposure before you build: if they rip us out tomorrow and keep the code, what breaks? The answer depends on whether the integration is a placement, a capability or a handoff, and it is worth asking during partner selection, not after.

7. Do partner-sourced users churn faster?

Often, yes. The founder who raised attribution added a second warning: check how many of those users are still active after a month, because people who only ever touch you through someone else's product often churn faster than people who found you directly. They were replying to our own case-study figure — 32% of the founders who clicked through from a partner's product created an Ordana account — and the challenge applies to that number as much as to anyone's. A conversion rate without retention beside it is a vanity number.

The fix:

• Group partner-sourced customers by the month they arrived and count how many are still active at 30, 60 and 90 days.
• Put the same curve for your direct customers next to it. Without that baseline, any retention figure is uninterpretable.
• If you share revenue, track the share of partner-sourced customers still paying in month two and three, not just the first charge.

Which SaaS integration problems should you fix first?

1. Before launch, on paper: the support split (4) and the exit terms (6). They cost an hour and they are the ones that end partnerships.
2. In the first build, in code: the credential rules (1), idempotent handlers plus the replay test (2), the tolerant reader (3) and degraded mode (4). These are patterns, not projects — put them in the instructions you give your coding agent.
3. Before the second deal: attribution at the source and a shared statement (5), and a retention cohort (7).

Notice the shape: three problems are engineering and four are agreements. That is why an integration that was "done" in a weekend can still fall apart in a quarter — and why it is worth choosing a partner worth integrating with in the first place.

On Ordana, members still build and maintain their own glue — we deliberately never hold a partner's credentials. What the platform covers is the other half: the integration terms carry notice periods for breaking changes and for exit, and the revenue share is calculated from one tagged record instead of two dashboards.

Related reading:

• Integration Partners Get Paid Nothing — And That's Why Integrations Rot — why the money side decides whether an integration gets maintained.
• Integration partnership agreements — what to write down before launch.
• Revenue share for integration partnerships — structuring the split.