Connect systems so they don't break each other — map the integration boundaries, design the event and webhook contracts, plan retries and failure handling, then document the integration.
Integrations are where two systems' assumptions collide, and the collision is rarely visible until production. A webhook fires twice, or never; a third-party API changes a field; a downstream system is down for thirty seconds and a hundred events vanish. The naive version — 'call their API when this happens' — has no answer for retries, ordering, idempotency, or partial failure, so it works in testing and loses data at scale. This workflow designs the integration as a contract with failure built in: the boundaries, the event shapes, the retry and failure strategy, documented before the first webhook fires.
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
Map the integration boundaries
Anchor the model as an architect and map where your system meets the others — the third-party APIs, the events crossing the boundary, the dependencies you don't control. You can't make an integration reliable until you know its edges.
Design the event and webhook contracts
Pin the shape of what crosses the boundary — the event payloads, the webhook schemas, the fields each side promises — so producer and consumer agree on a contract instead of discovering mismatches in production.
Plan retries and failure handling
Work the failure modes one at a time: retries with backoff, idempotency so a re-delivery doesn't double-charge, ordering, dead-letter handling, and what happens when the other side is simply down. This is the part the naive version skips.
Document the integration design
Capture the boundaries, contracts, and failure strategy in a spec both sides can build against and the on-call engineer can read at 2am when an integration misbehaves.
An integration designed to survive the real world — boundaries mapped, event and webhook contracts pinned, and retries, idempotency, and failure handling planned before launch — so connecting systems doesn't quietly lose data the first time a third party hiccups.
API design shapes the surface clients call into your system; this workflow designs the wiring between systems — outbound webhooks, inbound events, third-party calls — plus the retries, idempotency, and failure handling that keep them reliable. Use it when the risk is connections breaking, not endpoint shape.
Because integrations fail in the field, not in testing — a webhook double-fires, a service is briefly down, a payload changes. Designing idempotency and retries after launch usually means discovering the gap through lost or duplicated data first. It's far cheaper to design in.
A written integration spec: mapped boundaries and external dependencies, event and webhook payload contracts, and a documented retry, idempotency, and failure-handling strategy. Step 4 produces it in Markdown both sides can build against and an on-call engineer can read at 2am. NewPrompt supplies the prompts; you generate and review the spec.
Run the four prompts in order in your own AI tool: map integration boundaries, design event and webhook contracts, plan retries and failure handling, then document the design. NewPrompt gives you each step's prompt, tool, and resource link; you run them, review each output, and carry it into the next step.
The systems you're connecting and the events crossing between them, any third-party APIs and their payload shapes, your idempotency keys or unique identifiers, and known failure tolerances. Step 1 maps these boundaries; the more concretely you name the external dependencies you don't control, the sharper the contracts and retry strategy.
Check the design against the failure modes it must survive: replay a duplicate delivery against your idempotency plan, confirm every event has a retry and dead-letter path, and verify producer and consumer agree on each payload field. You own this review — the workflow structures it, it doesn't certify the design.
Complete build journeys that include this workflow as a stage.
The full path to an AI content moderation system — define the policy and label taxonomy, extract signals from user content, classify it against policy, emit structured decisions, evaluate false positives and negatives, wire enforcement and review queues, review abuse risks, then ship.
The full path to automation that survives the real world — wire the integrations and triggers, design the control API, move the data through validated stages, evaluate the AI steps, then deploy.
The full path to a support operation, not just a bot — stand up the knowledge base, route the tickets, add the AI agent, integrate your stack, close the feedback loop, evaluate, and deploy.
The full path to a booking and reservation system — model resources, availability, and reservations, design the booking API, set customer accounts, wire calendar and notification integrations, design the UI, review security, then ship.
The full path to an inventory management system — model products, stock, locations, and movements, design the inventory API, set roles, plan supplier and POS integrations, design the UI, review data-integrity risks, then ship.
The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.
The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.
The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.
Cross the gap between 'tests pass' and 'safe in production' — assess release readiness, plan the deploy and its rollback, and set up the monitoring and launch checks before you ship, not after.
Design an API on its contract instead of discovering it endpoint by endpoint — model the resources, design the endpoints and payloads, pin the contract, then review it before code locks it in.
Design a system's architecture on its real trade-offs instead of a confident diagram — put the model in an architect's seat, work the decisions one at a time, and write down the why.
Design a schema on its data, not a hunch — model the entities and relationships, set the constraints that protect integrity, plan indexes around real queries, then document the schema and migration.