An integration logo is not proof that two products work together.

First decide whether the integration deserves a page.

An integration request often starts with a logo. Sales wants the partner name on the site. Marketing sees a search phrase. Someone creates a page before the product team has confirmed what the connection does.

Start with a harder decision: should this claim be public at all?

Use this admission test. Mark each answer yes, no or unknown.

The first five answers must be yes before the claim becomes an indexable page. The last two need a named owner and a truthful next step. An unknown product fact is a hold. It is not space for a copywriter to guess.

The decision is one of four:

• Publish: the claim is verified, useful and owned.
• Consolidate: the answer is useful, but a directory, documentation page or another page already owns it.
• Hold: the integration may be real, but one or more material facts are not approved.
• Remove: the connection is unavailable, deprecated or cannot be supported truthfully.

Official marketplace rules point in the same direction. Google Workspace reviews both the listing and the app. Atlassian requires an app to perform as described. Those are platform-specific review rules, not a promise that every connection needs a marketing page.

Use the wider B2B SaaS buyer-question map when the real decision is whether any new URL should exist.

Show what moves, which way it moves and what access it needs.

A buyer wants to know whether the integration fits a real workflow. A benefits paragraph cannot answer that.

Use a short data-flow statement:

Do not say “two-way sync” when only one record type writes back. Do not say “all customer data” when the connection moves only contacts and account names. Do not describe a scheduled job as an immediate update.

HubSpot requires shared-data descriptions to be current and to reflect requested scopes. Slack’s marketplace rules address permissions and least-privilege access. Google Workspace policies require transparent data use and minimum necessary scopes.

Performance words need special care. “Instant,” “automatic,” “complete” and “secure” can create objective or implied claims. The FTC’s substantiation guidance says an advertiser needs a reasonable basis before an objective claim is published. The evidence needed depends on what a buyer is likely to understand from the wording and context.

Marketing can make this explanation readable. Product, engineering, security and privacy owners must approve the facts.

Put plans, regions, versions and purchase limits where buyers can see them.

The integration may work and still be unavailable to this buyer.

Show the material limits near the main compatibility statement:

Do not hide an upgrade behind “Get started.” If the connection needs a paid plan, name it. If the user needs a second licence, say so. If availability changes by country or version, put that limit before the install or sales action.

HubSpot’s listing rules require pricing information to match the plan that supports the integration. Shopify says a listing should let merchants know whether the app will work for them, including relevant geographic or API requirements. Atlassian requires disclosure of external account or licensing needs. For Microsoft 365 apps and agents linked to a SaaS offer, Microsoft requires limitations and specialized purchase flows to be stated in the metadata and plan details.

These details are part of compatibility. They are not fine print.

Test the real path and record what was tested.

A screenshot proves that someone saw a screen. It does not prove a complete integration path.

Testing belongs to product, engineering and QA. Those owners decide what level of testing is needed. A public evidence record can then state the approved scope without pretending that marketing ran the test.

Different tests answer different questions:

• A unit test checks one part of the integration logic.
• A contract test checks whether an external API still matches expected requests and responses.
• An end-to-end test follows a real path across the connected products.
• A user test checks whether the intended person can complete the workflow.
• Production monitoring can reveal auth, schema, token, rate-limit or other failures after launch.

AWS’s marketplace checklist includes entitlement, registration, metering and billing states. Zapier’s publication path moves through testing, review, beta and support documentation. A current Prismatic testing guide distinguishes unit, contract and end-to-end testing; it is practitioner evidence, not a platform rule.

Use a dated test label:

A TESTED-DATED label does not promise future uptime. It tells the buyer what evidence existed and where its boundary sits.

Keep the claim current when the product changes.

An accurate page can become wrong without anyone editing it.

An API changes. A permission is added. A plan moves. A partner stops supporting setup. The marketplace record enters review while the owned page still shows the old promise.

Set change triggers before launch:

Keep a small correction record for material changes: the date, what changed, which evidence was checked and whether the page was corrected, qualified, held or removed.

Slack says marketplace approval is only the beginning. Atlassian tells publishers to treat a listing as a living asset. Google Workspace documents draft, review and unpublish states. Those official records support a simple rule: publication creates a maintenance duty.

A “reviewed on” date is useful only when someone checked the material fields. The date itself is not proof.