Third-party Integrations
Let customers connect external systems via OAuth apps, with a marketplace, per-connector sync patterns, token rotation, and per-tenant governance.
Options
Integration Surface*
Sync Direction*
Connector Lifecycle*
Marketplace Governance
Decision Points
Native integrations only or open marketplace + generic API?
If yes
Open marketplace when integrations are a strategic moat or scale exceeds your team. Generic API provider when integrations matter but are not differentiating.
If no
Native-only is the right default until requests exceed what your team can ship. Quality stays high, surface stays bounded.
OAuth 2 app registration for third-party developers?
If yes
Developer dashboard with org verification, client ID/secret issuance, callback URL allowlists, and credential rotation. Substantial product surface.
If no
Keep apps internal — no external developer surface to build or support.
Fine-grained scopes per integration?
If yes
Per-scope consent at install, minimum-privilege defaults, and a scope catalog documented for users. Required for any serious marketplace.
If no
A single "full access" scope is a trust disaster at scale — only acceptable for strictly internal apps.
Approval workflow for marketplace listings?
If yes
Submission queue, reviewer checklist, metadata requirements (screenshots, privacy policy, support email), and a public listing policy.
If no
Self-publish marketplaces become low-signal fast. Only acceptable for developer-tool audiences that self-moderate.
Mandatory security review before listing?
If yes
Tiered review by scope sensitivity — low-risk apps skip heavy review, high-risk apps get penetration testing. Non-negotiable once sensitive data is in play.
If no
Only acceptable when scopes are strictly read-only and non-sensitive. Skip review and one compromised app hits every customer.
Revenue share with integration partners?
If yes
Billing, tax handling, payouts, and partner agreements become product scope. Real operational weight — treat as a separate program, not a feature.
If no
Free-to-list keeps the marketplace simple and focuses incentives on distribution rather than revenue.
Customer-visible integrations settings page?
If yes
List installed apps, connection health, last-sync time, scope review, and uninstall. The primary management surface — every marketplace needs it.
If no
Only acceptable for headless integrations (provisioned by admins via API). Otherwise support ends up doing every disconnect manually.
Sync direction: one-way, two-way, or configurable?
If yes
Configurable per connector. Make the default explicit per integration so customers do not have to guess direction during setup.
If no
One-way only — simpler and avoids conflict resolution entirely. Right for read-only analytics/enrichment cases.
Initial historical backfill or go-forward only on connect?
If yes
Backfill N days/months of history on connect; always async with progress UI. Plan for rate-limit backoff and multi-hour backfills on large accounts.
If no
Go-forward only — simpler and faster to onboard, but customers with existing data will complain their dashboards are empty.
Per-connection secrets storage and auto-rotation?
If yes
Encrypted per-connection credentials rotated on every refresh, with rotation events logged. Required for OAuth 2 providers with rotating refresh tokens.
If no
Only acceptable for static API keys. Will break the first time a partner enables refresh token rotation.
Reconnect flow surfaced when tokens expire?
If yes
Detect 401/403 on refresh, mark the connection as needs-reconnect, notify the owner, and offer in-app reconnect. Integrations silently dying is the #1 support ticket.
If no
Expired integrations will fail invisibly. Only acceptable for internal tooling with ops monitoring.
Integration health/status indicator for customers?
If yes
Show last-sync time, last-error, and a manual retry button on the settings page. Without it, customers discover failures via broken reports.
If no
Customers will assume everything works until it visibly does not. Strongly recommended even for small catalogs.
Rate-limit outbound calls to respect partner API limits?
If yes
Per-connection queuing, token-bucket or leaky-bucket, and partner-specific backoff. Getting throttled is a data issue; getting banned is a customer-facing outage.
If no
Only acceptable at very low integration volume. Miss this and customers blame your product for partner throttling.
Per-tenant allowlist of which integrations can be enabled?
If yes
Workspace admins explicitly approve integrations their members can install. Default-deny lists are worth offering for regulated industries.
If no
Any member can install anything. Regulated enterprise buyers will block the deal — ship allowlists before upmarket sales motion.
On uninstall: purge synced data or retain it?
If yes
Purge on disconnect — aligns with GDPR and partner DPAs. Document the purge behavior and offer an explicit retention setting for customers who want otherwise.
If no
Retain synced data after disconnect — easier to re-enable, but silent retention is a compliance hit. Must be disclosed.
Tradeoffs
Partner management, app review, security policy, and developer support become ongoing product work
Conflict resolution, idempotency, and reconciliation jobs turn every integration into a distributed system
Time-to-supported-connector drops dramatically; you inherit provider outages and abstraction limits
Onboarding looks instant but load on partner APIs and your workers spikes during early use
Implementation Examples
Unified-API provider covering HR, CRM, accounting, and ticketing with a single integration.
Open-source unified API and auth layer for third-party integrations, with per-connection token management.
Embedded integrations platform with customer-facing connect UI and managed auth/sync infrastructure.
Embedded integration platform aimed at SaaS products needing deep two-way connectors.
Connector runtime and auth infrastructure for embedding hundreds of integrations with minimal code.