What an Official SaaS Integration Page Needs to Establish

An official integration page has not established a connection just by saying two products integrate. It should let a buyer answer four practical questions without leaving the page: which method exists, what it does, whether their account can use it, and who supports it.

That means naming the exact route, its provider and maintainer, the direction data moves, the supported objects and actions, the prerequisites, the material limits, the current status, the setup route and the support owner. A buyer should not have to reconstruct one method from a directory tile, a launch post, a marketplace listing and an unrelated help article.

Two labels mark evidence boundaries on this page. Documented marks a product behaviour or platform requirement directly supported by the linked provider documentation. Any surrounding interpretation remains CoreAEX analysis unless separately attributed. Recommendation means a specification, template or workflow that CoreAEX prescribes and no source specifies. Marketplace rules quoted here apply only to the marketplace that publishes them. Findings from CoreAEX's own integration study are described in the prose with their sample and dates and are not tagged; they are first-party observations, not platform documentation. Untagged text is ordinary explanation or a conclusion following from something already labelled.

The page specification

The table below is the practical centre of this article. Each row is a fact the page should establish for one integration method, paired with the question it lets a buyer answer. It is a CoreAEX recommendation, not an external standard. The marketplace requirements cited later on this page differ from one another, and none of them is presented here as requiring this table.

Not every row will carry the same weight for every method. An embed may have no meaningful objects-and-actions list; a customer-built API route may have no vendor support owner. The point is that the page says so, rather than leaving the row for the buyer to infer.

Why “integrates with” is incomplete

“Integrates with” answers whether a connection exists. It does not say what kind of connection it is, and that is usually the part a buyer's decision depends on.

CoreAEX's own integration-accuracy study illustrates the gap from the answer side. On 30 deliberately selected product pairs, collected across four answer surfaces on September 8-9, 2026, 111 of 115 captured answers correctly identified whether the integration existed, while 44 of the same 115 were not fully accurate overall. The 115 are captured answers out of 120 attempts. Because the pairs were selected rather than sampled, those counts describe that sample only; they are not a rate for SaaS integrations generally, and “not fully accurate” includes answers that were partly right. The errors the study observed involved direction, method, capability, eligibility and current status, the details sitting behind the word “integrates.”

The same phrase can cover methods that behave very differently:

• An embed shows content from one product inside another.
• An import copies data in one direction, often on request.
• A one-way connector moves changes from a source to a destination, but not back.
• A two-way sync keeps records in agreement in both directions, within whatever fields it supports.
• An API route makes a connection possible, but someone still has to build and maintain it.

A buyer who reads “integrates with” and assumes the last-but-one of these, when the method is the second, has a correct answer to the first question and a broken plan. The sections below take the specification row by row, with a documented example where one helps.

Identify the exact route and its owner

One product pair can be connected by several routes: a native integration, a partner-built app, a marketplace app, an automation-platform connector, an embed, an import or export, or a customer-built connection through an API. These are possible categories, not a claim that every pair has all of them.

Where more than one route exists, the page should keep each capability list attached to the route it describes. A single list that merges what the native integration does with what a partner app does, or with what is possible through the API, leaves the buyer unable to tell which features arrive together. Give each method its own heading, or its own page, and say plainly which one the reader is looking at.

Ownership needs the same separation. Four relationships are easy to blur:

• Listed by - who published the marketplace or directory entry.
• Built by - who wrote the integration.
• Maintained by - who keeps it working when either product changes.
• Supported by - who a customer contacts when it fails.

A marketplace listing alone does not identify every one of those relationships. Appearing in a vendor's directory, carrying both products' logos or sitting in a particular listing category does not tell a buyer who built or supports the connection. Some listings do name a provider (Atlassian's listing for Jira Cloud for Google Sheets names Atlassian as the app provider, for example), but the page should still state maintenance and support directly rather than leave them to be inferred from the listing. Recommendation

None of this implies that one ownership type is more reliable than another. A partner-built app can be well maintained and a native integration can lag. The page's job is to say which applies, so the buyer can weigh it.

State direction, objects and actions

“Syncs with” is the phrase most likely to hide the detail a buyer needs. CoreAEX recommends replacing it with five explicit statements:

• Source → destination. Which system data leaves, and which it arrives in.
• Trigger and action. What starts the movement (a change, a schedule, a manual import) and what happens in the destination.
• Supported objects. Which records or fields are covered.
• Create, read and update behaviour. Whether the method creates new records, reads existing ones, updates them, or some combination.
• Whether edits travel back. If a record changes in the destination, does that change return to the source?

Two documented examples show why the last point in particular needs to be written down rather than assumed.

Field-level direction: Unito and Typeform

Unito's Typeform-specific guide marks the Typeform form, question and response fields it lists as one-way. Changes in those Typeform fields can move to a connected tool; changes made in the other tool do not sync back to those fields. Documented

This is a statement about the listed fields in that connector, not about Unito's integrations generally. It is exactly the kind of boundary a general description of a sync platform can obscure, and it is the kind a vendor page can state in one line. An illustrative way to write it:

Illustrative sentence: “Typeform to [connected tool]: one-way for the form, question and response fields listed below. Changes to those fields in Typeform move to [connected tool]; edits made in [connected tool] do not sync back to them.”

The placeholder stays a placeholder. The sentence states only the direction the guide documents, and a vendor using this pattern would fill in its own destinations and actions from its own documentation.

Import versus write-back: Jira Cloud for Google Sheets

Atlassian's Jira Cloud for Google Sheets (Official) listing describes importing Jira issue data into Sheets, using either the sidebar or the =JIRA() formula. Documented

The checked listing does not establish that this app writes spreadsheet edits back into Jira. That is a statement about what this listing documents, not a finding that no Jira-Sheets method can write back, and not a tested absence of the behaviour. Other routes between the two products are outside what this example covers.

The difference matters because an import makes the spreadsheet a reporting surface, while a write-back would make it an input to the issue tracker. A vendor page can close the question by stating both halves:

Illustrative sentence: “Jira Cloud for Google Sheets imports Jira issue data into Google Sheets through the sidebar or the =JIRA() formula. [State here whether edits made in Sheets are written back to Jira.]”

The bracketed line is deliberately left for the provider. Only the team that owns the method can say whether write-back exists; the page specification simply asks that the answer be on the page.

One related caution. Permissions an integration requests during installation (read and write access to certain records, for instance) are not a description of what the integration's workflow actually does. A page that implies two-way behaviour from requested permissions alone has not established it.

Place prerequisites and limits beside the capability

A capability can be described correctly and still mislead if the condition that limits it lives somewhere else. CoreAEX recommends putting each relevant condition (plan, role, account type, region, permissions, a required third-party account, usage limits) immediately next to the capability it restricts, and naming material exclusions with the same prominence as the features. Include only the conditions that apply to the method in question; not every method has every restriction, and a padded list hides the one that matters. Recommendation

Zendesk's guide to Answer Bot for Slack shows the pattern. Zendesk says the documented Answer Bot for Slack functionality applies only to customers who had a drafted or published AI agent using legacy AI-agent functionality as of February 2, 2025. Documented

That condition belongs to the legacy Answer Bot feature described in that guide. It is not a condition on the whole Slack for Zendesk integration, nor on newer Zendesk AI routes. But a description of the Answer Bot capability that omitted it could be accurate about the feature and still mislead readers who do not meet the documented condition.

Written at the capability, it might read:

Illustrative sentence: “Answer Bot for Slack: available only to customers who had a drafted or published AI agent using legacy AI-agent functionality as of February 2, 2025.”

The eligibility sits in the same line as the feature name, so a reader who sees one sees the other.

Show current status

An integration page that was accurate when written can stay online, on the vendor's own domain, after the method it describes has changed. Nothing about the page looks out of date unless the page says so. CoreAEX recommends giving each method, and where needed each capability, an explicit status from a small controlled set: Recommendation

• Current - available and supported as described.
• Beta - available with stated limitations on stability or support.
• Deprecated - still working, but no longer recommended for new use.
• End of support announced - a dated end has been published and has not yet passed.
• Retired - no longer available or supported.
• Historical - kept for reference by existing users; not a description of current behaviour.
• Replaced - superseded by a named successor method.

Status often applies to a single action rather than a whole app. Intercom's Stripe app guide says that the ability to send subscriptions via Messenger would cease to be supported from December 2025, and the same guide continues to describe other Stripe app functions as current. Documented

The ended action is that one Messenger capability; the Stripe app as a whole is not retired. The guide words the change in the future tense on a dated page, so read from October 2026 it is the provider's announced end for that action, not a behaviour CoreAEX has tested. A page following the specification would give the Messenger action its own status and date. The notice says nothing about the app’s other capabilities, so each of those would carry the status its owner has checked and confirmed for it, rather than being marked current by default.

When a method or capability ends, the choice between keeping the page with a visible historical label and redirecting it depends on continued user need. If existing customers still rely on the documentation to run, migrate from or wind down the old method, a clearly labelled historical page with a link to the replacement serves them. If nobody still needs it, a redirect to the current method's page avoids leaving an outdated description in circulation. Either way, the status should be visible at the top of the page, not buried in a changelog. That is a judgement about readers and URL context; it is not a claim that either action changes how other systems describe the product.

Divide the work between landing page and setup guide

The landing page and the setup guide do different jobs. The landing page should carry the decision-critical facts from the specification table (method, owner, direction, objects and actions, prerequisites, limits and status) so a buyer can decide whether the method fits. The setup guide should carry the method-specific installation, authentication, field mapping, testing and troubleshooting steps, and the landing page should link directly to it rather than to a general help centre. Recommendation

Marketplaces treat the setup guide differently, which is why no universal requirement can be claimed. HubSpot's setup-guide requirements call for a publicly accessible, integration-specific guide with installation and configuration steps for apps listed on its Marketplace, with further requirements for certification. HubSpot's listing requirements also ask for integration-specific content, accurate information about shared data and eligible pricing, and a support contact. Google Workspace's store listing guide requires a support link but treats a setup link as optional, recommending one when configuration needs explanation. Documented

Each of those rules applies to its own marketplace. The CoreAEX allocation above is a recommendation for the vendor's own integration page, whichever marketplaces the app also appears in.

Release and maintenance handoff

An integration page stays accurate only if someone is responsible for it when the integration changes. For this page type, the handoff can be short: Recommendation

1. The product owner approves the method and capability statements - what the integration does, in which direction, for which objects.
2. The documentation owner checks the wording, the prerequisites placed beside each capability, and the support path.
3. The maintainers update every relevant surface when a material fact changes: the landing page, the marketplace listing and the setup guide.
4. Status and last verified date are recorded on the page each time it is checked.
5. A material change triggers a recheck - a new or removed capability, a direction change, a new prerequisite, a status change or a change of maintainer.

Marketplace listings can carry their own obligations here. Slack's Marketplace guidelines, for example, require resubmission after substantial changes to an app's features, purpose or functionality; that applies to Slack Marketplace apps only.

No fixed review interval is prescribed here; the trigger is a change to the integration, not the calendar. For a fuller model of claim-level ownership, sources, checked dates and triggers, see Maintaining SaaS Competitor Comparison Pages. Where the integration page disagrees with a pricing page, a help article or a product page, How to Fix Conflicting Product Information Across Your SaaS Website covers reconciling them.

A copyable page template

The fields below turn the specification into a content model a team can reuse. Copy the field labels once for each specific integration method, not once per product pair. Fill in each bracketed placeholder from your own product documentation. Where a field does not apply to a method, keep the label and write “Not applicable” with a short explanation of why, rather than deleting it. Recommendation

• Integration and exact method: [the two products and the specific connection]
• Connection type: [native integration, partner app, marketplace app, automation connector, embed, import/export, or customer-built API route]
• Built by: [organisation that built this method]
• Maintained by: [organisation responsible for keeping it working]
• Support contact: [who customers contact and how]
• Current status: [current, beta, deprecated, end of support announced, retired, historical, or replaced]
• Direction: [source system] to [destination system]; [whether and for which fields edits travel back]
• Supported objects and actions: [records or fields covered and what the method creates, reads, or updates]
• Prerequisites: [applicable plans, roles, permissions, account types, regions, and third-party accounts]
• Limits and exclusions: [material things this method does not support]
• Setup guide: [direct URL and title of the method-specific instructions]
• Alternatives: [other methods between these products, if any]
• Last verified: [date the product owner confirmed these facts]
• Replacement or end-of-support notice, if relevant: [what changes, effective date, and successor method]

Built by, maintained by and support contact are separate fields on purpose. They are often the same organisation, and when they are, the page can say so in each field; when they are not, merging them is where a buyer's support expectations go wrong.

What this specification does and does not claim

The specification is meant to help a buyer assess a documented connection, and to give product, documentation and marketing teams a common reference for what an integration page should say. The four provider examples show individual fields in practice; they were chosen to illustrate distinct decisions, not to describe how common each problem is.

CoreAEX's integration-accuracy study observed answers about integrations; it did not test whether adding these fields to a page changes retrieval, citations or answer accuracy, and no such effect is claimed here. The case for a complete integration page rests on what it does for the reader in front of it: a buyer who can see the method, the direction, the conditions and the owner can make the decision without reconstructing it. This page describes product facts for a human buyer; how agents read tools and actions is covered separately in SaaS Documentation for AI Agents.

---

Sources