Plan the webhooks and integrations between your stack tools
Produces a full integration architecture for your GTM stack: connection map, webhook event catalog, a source-of-truth table per field, idempotency and retry rules, failure detection, and a dependency-aware build order. It prevents the classic outcome — five tools, six versions of the truth — by settling ownership before anything gets wired.
You are an integration architect who has wired hundreds of GTM stacks together and untangled the aftermath of many more, where six tools each thought they owned the truth and every sync was a fresh way to duplicate data. Your principles: one direction of truth per field, idempotent everything, and no integration without a failure plan. Plan the integrations for my stack. Output: 1. INTEGRATION MAP — a plain-text diagram of every connection: source tool, destination tool, transport (native integration, webhook, polling, middleware like n8n/Zapier), and direction. 2. EVENT CATALOG — for each webhook: the triggering event, the payload fields that matter, and what the receiver does with them. 3. SOURCE OF TRUTH TABLE — for each shared field (email, stage, owner, enrichment data): which system wins conflicts, and which direction it syncs. 4. IDEMPOTENCY AND RETRIES — how duplicate deliveries are absorbed (dedupe keys, upserts not inserts), retry policy per connection, and rate-limit handling for each API. 5. FAILURE PLAN — per connection: how you'd know it's down (heartbeat, volume anomaly), where alerts go, and the manual fallback while it's broken. 6. BUILD ORDER — which integrations to build first based on value and dependency. Rules: no bidirectional sync on any field unless I explicitly defend why. Prefer native integrations over custom webhooks when they carry the needed fields; say when they don't. Every webhook receiver must tolerate the same event arriving twice. Before you plan, interview me. Ask ONE AT A TIME, waiting for my answer each time: 1. List every tool in the stack and its job in one line each. 2. Which data currently gets re-typed by hand between tools? 3. Where have you seen duplicates or conflicting data appear? 4. What middleware do you have (n8n, Make, Zapier), if any? 5. Which single integration, if it broke for a week, would hurt most? Then produce the plan. If two tools in my stack fight over the same job, flag it before designing around it.
How to use it
- 1
Copy the prompt into Claude, ChatGPT, or any LLM.
- 2
Answer the interview; question 2 (hand re-typed data) is where the highest-value integrations hide.
- 3
Build in the specced order, testing each connection's duplicate-delivery behavior before moving on.
- 4
Keep the source-of-truth table in your ops docs — it settles most future data arguments in one glance.
Best practices
Fight the urge to sync everything; each field synced is a maintenance liability, so sync only fields something downstream consumes.
Test idempotency deliberately by replaying the same webhook twice and confirming exactly one record changes.
Route all custom webhooks through your middleware rather than point-to-point — one place to see, log, and fix everything.
Revisit the map every time a tool is added or dropped; stale integrations from departed tools are a silent error source.
Example: what this looks like in practice
A RevOps team of two at a 70-person SaaS runs HubSpot, Smartlead, Clay, a call tool, and a billing system, with SDRs re-typing positive replies into HubSpot and enrichment data pasted between tabs. The interview flags HubSpot-Smartlead as the most painful potential outage and n8n as available middleware. The plan comes back with seven connections: Smartlead reply webhooks through n8n into HubSpot upserts keyed on email, Clay pushing enrichment one-way into HubSpot with HubSpot as truth for lifecycle stage and Clay as truth for firmographics, and a heartbeat workflow that alerts when reply volume flatlines for a day. Build order puts the reply sync first. Two weeks in, manual re-typing is gone and a Smartlead webhook outage gets caught in hours instead of being discovered at the Friday pipeline review.
Best fit
This prompt is one gear in a bigger machine. We orchestrate 20+ tools into outbound systems our clients own — and guarantee the results.
Apply for a Pilot Spot → →Frequently asked questions
A webhook is one tool notifying another the moment something happens — a reply lands, a meeting books, a form submits — by sending a small data payload to a URL. In sales stacks, webhooks are how events flow in real time from sequencers and calendars into CRMs and Slack without polling or manual re-entry.
More automation & workflow design prompts
Build a system prompt for an AI cold email reply agent
Interviews you about your offer, booking flow, and voice, then generates a complete production system prompt for an AI reply agent — classification taxonomy, response rules, escalation conditions, and a strict JSON output contract an n8n or Zapier workflow can parse. You get the artifact teams pay thousands to have written, tuned to how you actually talk.
Turn a manual sales process into an automation blueprint
Converts a fuzzy 'we do this by hand every week' description into a structured blueprint with a detectable trigger, labeled steps, edge cases, human checkpoints, and failure alerts. It forces the design decisions people usually discover mid-build, so what you hand to n8n, Zapier, or an ops hire is assembly work, not archaeology.
Architect a Clay table before you burn the credits
Designs the Clay table before you build it: sources, column order, run conditions, waterfalls, outputs, and a credit estimate. Column ordering and gating are where most teams silently overspend, so the prompt enforces filter-first architecture and makes every paid column defend its run condition — typically cutting credit burn 40-70% versus enrich-everything builds.