People and systems
Declare an actor for a person and participants for the applications, services, or data stores involved.
Interactions over time
Mermaid Sequence Diagram Online Editor
Describe an API request, a checkout interaction, or a service call in the order messages occur. Use the Mermaid sequence diagram editor above to review participants, alternatives, and responses before exporting the result.
Build a Mermaid sequence diagram online
The example separates validation failure from a successful database write. Paste your own sequenceDiagram source or adapt the example below.
Loading diagram preview...
Show who sends each message and when
An interaction diagram makes service boundaries and failure responses visible. It is useful for API reviews and incident explanations where a process flow alone hides who does the work.
Request and response paths
Use distinct arrow styles and precise message labels so readers can follow what crosses each boundary.
Success, failure, and repetition
Use alt for alternatives, opt for optional work, and loop for messages repeated under a stated condition.
Message order and notes
Number messages with autonumber and add a note where a timeout or contract needs explanation.
Document one request from start to finish
Keep each diagram focused on one interaction, including the failure path that changes the outcome.
- 01
Declare sequenceDiagram and the participants in the order you want them displayed.
- 02
Add messages from top to bottom, then group success and failure responses in an alt block. Close every block with end.
- 03
Read both outcomes in the preview, then export the diagram or share the current draft with a reviewer.
Sequence diagram syntax for messages and conditions
The source order determines the message order. Arrow styling helps communicate a convention; it does not enforce network behavior.
Mermaid sequence diagram syntax reference →Participants, actors, and aliases
Explicit declarations control the left-to-right order. An alias keeps a short source ID while showing a clear responsibility to readers.
sequenceDiagram
actor Customer
participant API as Orders API
Customer->>API: Create orderRequests and responses
A solid arrow with a head uses ->>; a dashed one uses -->>. Requests and responses are a useful labeling convention, not a check that a call is synchronous.
sequenceDiagram
Client->>API: GET /orders
API-->>Client: Order listAn alternative outcome
Only the differing messages belong inside alt and else. Put validation before the write when the failed request must not be stored.
sequenceDiagram
Client->>API: Create order
alt Valid order
API->>DB: Save order
API-->>Client: Confirmation
else Invalid order
API-->>Client: Validation error
endRepeated messages and numbering
Use loop to describe repetition and autonumber to number messages. The loop condition is display text, not executable control flow.
sequenceDiagram
autonumber
loop Until ready
Client->>API: Check status
API-->>Client: Current status
endActivation bars and notes
Use activate and deactivate to mark a participant’s activity during an interaction. A note adds context beside a lifeline; neither element measures elapsed time.
sequenceDiagram
participant Client
participant API as Orders API
Client->>API: Create order
activate API
Note right of API: Validate request
API-->>Client: Confirmation
deactivate APIMermaid sequence diagram example
A user submits a request through a web application. The API validates it before entering either the successful write path or the validation-error response.
sequenceDiagram
actor User
participant Web as Web App
participant API
participant DB as Database
User->>Web: Submit request
Web->>API: POST /requests
API->>API: Validate request
alt Request valid
API->>DB: Store request
DB-->>API: Request ID
API-->>Web: 201 Created
Web-->>User: Show confirmation
else Validation failed
API-->>Web: 400 Validation error
Web-->>User: Show corrections
end- The database appears only in the Request valid branch; rejected input is not written.
- Dashed responses carry the result back through the Web App to the user.
- Try adding an opt Send email block after the successful write, without changing the failure path.
Frequently asked questions
How do I change the order of participants?
Declare actor and participant lines in the desired order before the messages. Without explicit declarations, participants are introduced in their order of appearance.
When should I use actor instead of participant?
Use actor when the human-style symbol helps identify a person or external role. Both declarations create a lifeline; applications and services commonly use participant.
How are alt, opt, and loop different?
alt describes alternative branches and can include else; opt encloses optional interaction; loop describes repeated messages. Each block needs its closing end.
How do I add an activation bar?
Place activate API after the incoming message and deactivate API after the response. Match each activation with a deactivation. The bar shows the activity you model, not a measured response time.
Why is there an end-related syntax error?
Check that each condition or loop block has a matching end. If the word end is needed in a message or label, enclose it in quotes, parentheses, or brackets rather than leaving it bare.
Can I show parallel work?
Yes. Use a par block with and to separate concurrent branches. It describes the interaction and does not measure real execution timing.
Learn the syntax
Design readable Mermaid sequence diagrams
Learn how to model participants, messages, alternatives, loops, asynchronous events, and maintainable interaction boundaries.
Read the Mermaid sequence diagram guide →