Integration breadth proof
Prove the product by the systems it already reaches: name the job, show the connections, then walk one path end to end.
Section sequence
6sections, in the order the visitor meets them. Bar height is the section's weight in the page.
- OrientJob statement
- ProveConnected systems field
- ProveCoverage count
- DemonstrateOne path, end to end
- ProveCredentials and control strip
- ConvertThree-way exit
How the page argues
- 1
Name the job in the visitor's terms before naming a single connector.
- 2
Show the connected systems as a scannable field, dense but readable.
- 3
Quantify the breadth once, with a countable number that carries its unit and date.
- 4
Walk one concrete path from trigger to result, so breadth becomes capability.
- 5
Answer the credentials question in a short strip: auth, scopes, audit.
- 6
Fork the exit three ways — start free, read the docs, talk to someone.
What each section has to be
- OrientJob statement
- One sentence of outcome with no connector names yet, so breadth reads as means rather than identity.
- ProveConnected systems field
- A dense but legible grid of recognizable systems. Every mark must be a live integration, not a roadmap item.
- ProveCoverage count
- One countable number with its unit and as-of date, placed against the grid it summarizes.
- DemonstrateOne path, end to end
- A single trigger → steps → result walkthrough using real system names taken from the grid above.
- ProveCredentials and control strip
- Auth model, scope granularity and audit surface in three factual lines — enough to survive a security question.
- ConvertThree-way exit
- Start free, documentation and contact as visibly different destinations, not one form with three labels.
Is this the right sequence?
Who it is for
Technical operators and platform buyers who are quietly checking whether their own stack appears in your list.
Products it suits
Automation platforms, APIs and agent infrastructure whose value rises with every system they can reach.
Not for
A focused product with one closed workflow, where a wall of connectors implies the core job is unfinished.
Evidence strategy
Which proof modes carry the page, in the order they land.
- Primary: countable breadth the visitor can check against their own stack.
- Secondary: one worked path, which turns an inventory into a demonstrated capability.
- Tertiary: named auth and audit controls, so reach does not read as sprawl.
CTA plan
What the page asks for, what it offers instead, and where.
- Primary
- Start free, ideally pre-scoped to the connector the visitor just recognized
- Secondary
- Documentation for the full integration list, plus a coverage-request contact route
- Placement
- Start CTA immediately after the worked path; docs and contact repeat in the exit block and the footer.
Responsive behavior
What the sequence has to do when the viewport stops cooperating.
- The systems grid reflows from a wide multi-column field to a two-column scroll block; never a horizontal logo strip that hides half the coverage.
- The end-to-end path stacks vertically on small screens, with connector arrows becoming downward chevrons.
- The coverage count moves above the grid on mobile so the number is read before the scroll begins.
Anti-patterns
The failure modes that make this sequence stop working.
- A logo wall with no worked path: breadth without a demonstrated route reads as a directory, not a product.
- Counting planned, deprecated and community-maintained connectors inside the same headline number.
- Naming integrations before the job, which makes the product sound like plumbing rather than an outcome.
Build spec
ProWhat an agent needs in order to build Integration breadth proof: what each section must contain, the copy rule that keeps it honest, the slots to resolve from your product, and the order to build in.
Agent tags
The vocabulary an agent matches this recipe on.
- integration-breadth
- connector-grid
- worked-path
- coverage-count
- developer-exit