How it all connects

SendMock has many screens, but one idea explains all of them:

Everything your app sends becomes a message and an event. Everything SendMock sends back to your app is a delivery.

The mapCopy Anchor Link

                     ┌──────────── Settings change how capture behaves ────────────┐
                     │ outcome rules, profiles, chaos, OTP patterns, retention     │
                     ▼                                                             │
Your app ──SMTP, provider APIs, HTTP──►  CAPTURE                                   │
                                         Mail · SMS · Verify · HTTP · Payments     │
                                         (Logs keep the raw SMTP sessions and      │
                                          API requests behind each one)            │
                                              │                                    │
          Simulate buttons, Reply as          │ events: email.received,            │
          recipient, Verify force,  ─────────►│ sms.status, verify.started,        │
          payment Simulate, checkout page     │ http.captured, payment.succeeded   │
                                              ▼                                    │
                                         DELIVER                                   │
                Webhooks > Rules ──► Endpoint (Template + Variables + Secret) ─┐   │
                Inbound routes (incoming email) ───────────────────────────────┤   │
                Number reply webhook (incoming SMS, TwiML back) ───────────────┤   │
                SMS status callback (per message) ─────────────────────────────┤   │
                Gateway notification (IPN, payment webhook) ───────────────────┤   │
                Send to webhook, Composer, Saved (by hand) ────────────────────┘   │
                                              │                                    │
                                              ▼                                    │
                              Webhooks > Deliveries (log, retry, replay) ──► Your app
                                              │
                                              ▼
                              Overview and Webhooks > Overview (health), bell (alerts)

Read it top to bottom:

1. Capture. Your app talks to SendMock the way it talks to the real service. Each message lands in its menu (Mail, SMS, Verify, HTTP Catcher, Payments), and the raw conversation behind it (the SMTP session, the API request) lands in Logs.
2. Events. Every capture fires an event, such as email.received, sms.status, verify.started, http.captured or payment.succeeded. You can also make events happen yourself: Simulate a bounce, reply as the recipient, force a Verify outcome, refund a payment.
3. Deliver. Events turn into requests to your app. Rules pick events and send them to an endpoint, which shapes the request with a template, fills it with variables and signs it with its secret. Some deliveries do not need a rule, because a real provider would send them anyway: a message's status callback, a number's reply webhook, an inbound route, a gateway's payment notification.
4. Log and replay. Every request SendMock sends is in Webhooks > Deliveries, with the response your app gave, retries and Replay.
5. Watch. Overview and Webhooks > Overview summarise everything; the bell flags failures.
6. Settings decide how capture behaves: which addresses bounce, which numbers fail, how fast SMS are delivered, how payments settle, what counts as a one-time code.

Menu by menuCopy Anchor Link

Three journeys, screen by screenCopy Anchor Link

A password reset emailCopy Anchor Link

1. Your app sends the reset email over SMTP. The session shows in Logs > SMTP.
2. The email shows in Mail, with the reset link and any code extracted.
3. The email.received event matches a rule in Webhooks > Rules, say "everything to support@".
4. The rule's endpoint (Webhooks > Endpoints) uses the Postmark inbound template, so the request looks like Postmark's.
5. Webhooks > Deliveries logs the request and your app's answer. A 500 can be fixed and replayed.

An OTP login by SMSCopy Anchor Link

1. Your app starts a verification with the Twilio Verify API. SMS > Verify shows the code and its countdown.
2. The code goes out as an SMS, which shows in SMS as a conversation.
3. Each status change (queued, sent, delivered) calls the message's status callback, logged in Webhooks > Deliveries.
4. In the Verify drawer you can Expire the code or force Max attempts to test the error paths.

A checkoutCopy Anchor Link

1. Your app creates an SSLCommerz session. The payment shows in Payments as pending, and the API call in Logs > API requests.
2. The customer is sent to the test checkout page, which offers the gateway's methods. They pay with a test bKash number, OTP and PIN.
3. SendMock redirects the browser to your app's success URL with the gateway's fields, and posts the IPN through the gateway's notification endpoint; it shows in Webhooks > Deliveries.
4. Later, Simulate > Refund on the payment sends a second notification.

Every menu pageCopy Anchor Link

Overview · Mail: Providers · SMS: Verify, Providers · Push · HTTP Catcher · Webhooks: Endpoints, Rules, Inbound routes, Deliveries, Composer and Saved, Templates, Variables · Payments: Gateways, Methods, Flows, Subscriptions · Numbers · Scenarios · Logs · Settings

Where to go nextCopy Anchor Link

• What can I test? maps problems to these menus.
• Recipes walk through common tasks.