AI Sequence Diagram from Description

Turn an API description into a sequence diagram with actors and arrows.

Try one of these — click to open in the generator

OAuth 2.0 authorization code flow: user clicks login on client app, redirected to auth server, logs in and consents, auth server returns authorization code to client via redirect, client exchanges code + secret for access token, uses token to call resource server API.

Try it →

Stripe checkout with webhook

Stripe checkout flow: frontend creates payment intent via backend, backend calls Stripe API, Stripe returns client secret, frontend confirms payment on Stripe's side, Stripe sends webhook to backend on success, backend fulfills order and notifies frontend via WebSocket.

Try it →

Distributed transaction with saga

Saga pattern: order service creates order (pending), publishes event, payment service charges card and publishes result event, on success inventory service reserves stock, on failure payment service compensates by refunding. Order service listens for all events to finalize state.

Try it →

WebSocket chat message delivery

WebSocket chat message: client A sends message via WebSocket to server, server persists to database, server pushes message to client B (recipient) over their WebSocket, client B sends read receipt back, server updates message status and notifies client A.

Try it →

When to use AI Sequence Diagram from Description

API integration docs
When your REST or GraphQL API has multiple endpoints calling each other — auth, rate limiting, retries, webhooks. Sequence diagrams make every call traceable: who hit what, in what order, with what response.
Authentication & authorization handshakes
OAuth 2.0, SAML, JWT refresh, WebAuthn — any protocol where multiple parties exchange signed tokens. A sequence diagram forces you to name each actor and every message. Ideal for security review docs.
Distributed system message flows
Microservice choreography, event-driven pipelines, message queues (Kafka / RabbitMQ), WebSocket / SSE push. When there's no single orchestrator, a sequence diagram shows which service publishes what and who consumes it.
Database transactions & locking
Multi-step transactions with read/write locks, optimistic concurrency, two-phase commit. Sequence diagrams clarify the exact order of BEGIN, SELECT FOR UPDATE, INSERT, COMMIT — and what happens on lock timeout.
Event-driven architectures
Domain events fan out to subscribers, sagas coordinate long-running workflows, CQRS commands trigger event streams. A sequence diagram is often clearer than tracing spans when you want the whole story on one page.

Building a sequence diagram from a description that says almost nothing

A one-line prompt gets you arrows, but the model has to guess every actor you didn't name and every failure path you didn't mention. Chat mode asks about the one thing that reorders the arrows, drafts the rest, and then tells you which actors it invented. Here is a mobile access-token refresh flow, built from an opening line that says almost nothing.

Draw how our mobile app deals with an expired token.

AskUserQuestion

When does the app refresh — does it check expiry before sending a request, or does it react to a 401 and retry?

Refresh proactively before the token expires

Wait for a 401, refresh, then retry the original request

Both — proactive refresh with a 401 fallback

First draft — the 401-then-retry ordering came straight from your answer. The gateway, the token store and the rotation step are all inference, and get listed below instead of asked about.

I filled in a few things you didn't mention

Rotated the refresh token on every refresh — a used one is never valid again
Routed every call through an API gateway instead of letting the app hit services directly
Added a Redis token store behind the auth service to hold refresh token records
Used GET /orders as a stand-in for the request that hit the 401
Drew requests as solid arrows and responses as dashed async ones

Looks goodRemove 1

Dropped the Redis token store. The auth service now looks the refresh token up on its own.

Now show the replay case: someone posts a refresh token that was already rotated, auth revokes the whole family and the app has to sign in again. And don't put a separate token store back in — refresh tokens live in the auth service's own database.

Final sequence diagram. The exclusion you stated in chat holds for the rest of the conversation.

Four messages produced a sequence diagram with 401-triggered refresh, refresh token rotation, a retry of the original request, and a reuse-detection path that revokes the family — none of which were in the opening line. Sent one-shot, the same sentence would have drawn one client, one server, and a happy path, and you would have been the one to notice the replay case was missing.

Start this conversation →Opens the generator in chat mode with the first message already filled in.

Deep dive

Sequence diagrams are the sharpest tool when the story is about ordering and timing between multiple actors. Reach for them any time you need to show "who calls whom, in what order, with what response" — API integrations, authentication handshakes (OAuth, SAML, JWT refresh), distributed system message flows, database transactions with locks, WebSocket / SSE push patterns.

They're the go-to for engineering docs because they force you to name each actor explicitly — you can't hand-wave "the backend does something." Every arrow has a source, a target, and a message. This makes them ideal for architecture review docs and RFCs where the reader will pick apart every interaction.

A rough rule: if you find yourself saying "and then, and then, and then" more than three times in your explanation, you want a sequence diagram, not a flowchart. Sequence diagrams excel with async messages, activation bars showing when an actor is doing work, and notes annotating why a particular arrow matters. They struggle when the interaction is truly parallel with no meaningful ordering — in that case, a component diagram fits better.