Building Integrations and Plugins for SaaS Marketplaces
An integration listed in a well-known marketplace can bring users to your product. Building one that survives API changes and review processes takes some care.
Most business software does not live on its own. Customers expect it to connect to the tools they already use: their chat app, project tracker, e-commerce platform, payments and accounting. For a product company, integrations are both a retention feature and a distribution channel. A listing in a popular marketplace puts your product in front of people who are already looking for a solution.
Integrations also have a reputation for becoming a maintenance burden. Third-party APIs change, tokens expire, webhooks arrive twice or not at all. This post covers how we plan and build integrations that hold up over time.
Talk to customers before choosing which platform to integrate with first. Ask which tools they use daily and where they currently copy data by hand. The integration that removes the most manual copying is usually the one that gets used, whatever the marketplace's size.
Decide what the integration is for
Start with the job, not the API. Is the integration meant to bring data into your product, push your product's output somewhere else, or let users act on your product without leaving another tool? A notification bot, a two-way sync and an embedded app inside another platform are very different projects in scope and risk. Two-way sync in particular is far harder than it looks, because conflicts and deletions have to be handled on both sides.
It is also worth deciding early whether you are building one integration or an integration capability. If your roadmap includes several, the shared parts (connection management, credential storage, retries, logging, a settings screen for customers) should be designed once. Teams that build their first three integrations independently usually end up rewriting all three.
The building blocks
- Authentication. OAuth flows, token storage encrypted at rest, refresh handling and a clear path for users to reconnect when access is revoked.
- Webhooks. Signature verification, idempotent handlers (the same event may arrive more than once) and a queue so slow processing never causes the sender to time out.
- Rate limits. Respect the provider's limits with backoff and batching, and design so a burst from one customer cannot exhaust shared quota.
- Data mapping. An explicit, versioned mapping between their model and yours, with sensible handling of fields that do not exist on one side.
- Observability. Per-customer logs of sync runs and failures, so support can answer why something did not appear without involving an engineer.
Design for failure
Every external API will fail at some point: timeouts, outages, expired credentials, unexpected payloads. A robust integration treats failure as normal. Retries use exponential backoff with limits. Failed events go to a dead-letter queue that someone can inspect and replay. A periodic reconciliation job compares records on both sides and repairs drift caused by missed webhooks. And users see a clear status, such as connected, syncing or needs attention, rather than silently stale data.
Examples from our projects
Integrations show up in most of what we build. Sumus, an AI product-discovery engine for fashion, includes Shopify in its stack alongside a NestJS backend. Digital Arrow, the HR and recruiting platform we architected, lists Slack and Jira among its technologies and uses Browserless for headless document generation, including online contract signatures. In each case the integration code is isolated behind its own module, so a change in a third-party API touches one place.
Security reviewers on the customer side will ask how tokens are stored, who can access them and what happens if your service is compromised. Keep credentials encrypted with keys managed separately from the database, scope them to the minimum needed and make revocation immediate. Document this once and reuse the answer in every security questionnaire.
Getting through marketplace review
Most marketplaces review apps before listing them, and the requirements tend to look similar:
- Request only the permissions you actually use, and explain why each one is needed.
- Publish a privacy policy and terms that describe exactly what data you access and store.
- Provide a test account and clear instructions for reviewers.
- Handle uninstall cleanly, including deleting stored data where the platform requires it.
- Meet the platform's design and accessibility guidelines for any embedded interface.
Build these into the plan from the start. Retrofitting minimal permissions and data deletion after a rejection costs more than designing for them.
Treat the listing as a product
A marketplace listing is a sales page. Clear screenshots, a short explanation of what the integration does, setup instructions and a support contact all affect how many people install it. Track installs, activation (users who complete setup) and retention separately; a high install count with low activation usually points to a confusing setup flow rather than a lack of interest.
Version your own side of the integration too. When you change how data is mapped, existing customers should not see records suddenly change shape. Migrate them deliberately, with a note in the changelog, and keep the previous mapping available until everyone has moved.
Plan for maintenance
An integration is a long-term commitment. Subscribe to the provider's developer changelog, run automated tests against their sandbox on a schedule, and alert on rising error rates per integration. Budget time every quarter for API version upgrades. If you offer several integrations, a shared internal framework for auth, retries and logging pays for itself quickly.
Finally, give customers control. Let them choose what syncs, pause the integration without losing configuration and see a history of what changed. Customers trust integrations they can understand, and they disconnect the ones that surprise them.
Adding AI to an integration
Many recent marketplace apps use AI to do something useful with another product's data, such as summarising time entries, classifying tickets or drafting reports. The same rules apply as for any AI feature: be explicit about what data is sent to which model, evaluate output quality, and let users review results before anything is written back to their system. Our post on choosing between an agent and a workflow helps decide how much autonomy such a feature should have.
Need an integration built?
We build integrations, plugins and the platforms around them. See our web development service, or get in touch to discuss what you want to connect.
