An integration page should answer what a technical evaluator would otherwise ask on a call: what data moves, in which direction, how often, on which plans, with what permissions, what does not sync, and who supports the connector when it breaks. A logo and the words "connect in one click" answer none of that. Give each integration buyers ask about by name its own page, written from the engineers and documentation that already hold the details.
For many software purchases, integration is where an evaluation stalls. The champion likes the product, then the system administrator asks whether contacts sync both ways and what happens to custom fields, and nobody on the buying side can find out without booking a call. A marketplace tile or a logo wall tells the administrator only that some connection exists.
This page covers content planning for SaaS product marketing teams. It is not security or engineering advice; your engineers and security team confirm what an integration page may state.
What an evaluator needs from the page
Use a fixed brief for every integration page so the same questions get answered every time. The brief below works for most connectors.
| Brief field | What the page should state |
|---|---|
| Direction | One way or two way, and which system wins when records conflict |
| Objects and fields | Which record types sync, which standard fields map, and whether custom fields are supported |
| Timing | Real time, on a schedule, or on a trigger, in plain terms |
| Plans | Which of your plans include the integration, and whether the other system requires a particular plan |
| Permissions | The access the connector requests and why it needs each one |
| Limits | Record caps, rate limits, history that does not import, and known gaps |
| Setup | The steps, who performs them, and what admin rights they need |
| Disconnecting | What happens to synced data when the connection is removed |
| Ownership | Who built the connector and who supports it |
A page that fills every row is longer than a logo tile, and that is the point. The evaluator reading it is trying to decide whether to bring in IT, and every unanswered row is a reason to wait. Write the rows in the order an administrator would check them, and keep the language plain enough that the champion can forward the page without a translation from engineering.
Permissions deserve their own section
Many connectors authorize through OAuth 2.0. The framework's specification, RFC 6749, says "The authorization and token endpoints allow the client to specify the scope of the access request," and notes the authorization server may "fully or partially ignore the scope requested by the client." In practice, the scopes a connector requests are what a security reviewer looks at first, because they define what your product can read or change in the customer's other system. Before publishing, ask the engineer who owns the connector, "Which permission does this integration request that we could not explain to a security reviewer in one sentence?" If any scope fails that test, the page is not the place to fix it, but the engineering team will want to know.
List the requested access in plain language, grouped by what it lets your product do. Write "reads contacts and companies; creates notes on deals" rather than pasting raw scope strings, and link to the technical reference in the documentation for anyone who wants the exact names.
Native, partner-built, and third-party connectors
Buyers assume a logo on your integrations page means your team stands behind the connection. That is not always true: some connectors are built and supported by your engineers, some by the other vendor, and some run through a third-party automation tool. A listed integration is not a supported integration. Say on each page who built it, who maintains it, and where a customer goes when a sync fails, so a buyer does not learn the answer from a support ticket.
The same honesty applies to roadmap items. If an integration is in beta or planned, label it that way and leave it off any list of current capabilities.
Hundreds of templated pages help no one
Some SaaS sites generate an integration page for every app in a connector catalog, with the same three paragraphs and a swapped name. Google's spam policies define scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings" and not helping users, and list "Using generative AI tools or other similar tools to generate many pages without adding value for users" as an example. Write full pages for the integrations your buyers name in sales calls and support tickets; a searchable directory can cover the long tail without pretending each entry has a page's worth to say.
Here is a fictional example. A procurement software company in Georgia has an integration with a widely used ERP that drives most of its enterprise deals, and its page for it is two sentences long. The integration engineer can explain, in an hour, which purchase order fields map, why approvals sync one way, and what breaks when the customer uses a custom approval chain. The writer should not have to work any of that out from screenshots or invent it from the marketplace listing; the engineer already knows it and can review the draft. The rewritten page fills every row of the brief and links to the setup guide in the documentation.
Keep the page tied to the documentation
Integration details change with releases on both sides of the connection, so the marketing page and the help center need to stay in step. One practical rule: the marketing page states what the integration does and its limits, and links to the setup article for how. When an engineer updates the setup article, the content plan flags the marketing page for review. How documentation and marketing content work together covers that division in more detail, and how to explain implementation and onboarding covers where integration setup sits in a rollout.
Integration content follows Hudson South's usual sequence. Authority Asset gathers the connector documentation, field maps, and the explanations your integration engineers give. Hudson Twenty-One records your team's communication habits across 21 dimensions, so the page reads at the technical level your evaluators expect. Market Intelligence researches which integrations buyers in your category ask about and what competing vendors state about theirs. AEO Creation turns those inputs into integration pages that answer first and keep their limits visible. For the full set of pages a software site needs, see the software and SaaS content overview.
Compare your integration pages with your competitors'
Pick the integration that comes up in most of your deals. During a free 30-minute call, we review how your page and competing vendors' pages answer an evaluator's questions about it.
Get your free competitor analysisSources
- RFC 6749: The OAuth 2.0 Authorization Framework. RFC Editor. Read 2026-10-16.
- Spam policies for Google web search. Google Search Central. Read 2026-10-16.