Two scenarios, one HTTP module each — map your trigger's fields into ReplyTime's webhook body.
In ReplyTime, go to Settings → API Keys and create one named after this scenario, e.g. “Make — production.” Copy the secret immediately — it's shown only once.
Start with a trigger module for wherever your clients message you (Gmail, Slack, WhatsApp Business, Zendesk, or a webhook of your own). Add an HTTP → Make a request module, method POST, to the URL below.
https://replytime.net/api/v1/events/inbound
Set the headers for auth, choose Body type: Raw / JSON, and map the trigger bundle's fields into client, channel, and message.
Authorization: Bearer rt_xxxxxxxxxxxxxxxxxxxxxxxx Content-Type: application/json
Clone the scenario, trigger it on your own reply instead, and point the HTTP module at /api/v1/events/outbound. This is the scenario that stops the clock.
Run the scenario once with real data, then check the client's conversation in the ReplyTime dashboard — the countdown should start and stop as expected.
Both endpoints accept the same shape. Set message.source_tool so you can tell where an event came from later.
{
"client": { "external_ref": "acme-corp", "name": "Acme Corp" },
"channel": { "type": "email", "identifier": "support@acme.com" },
"message": {
"occurred_at": "2026-09-09T10:15:00Z",
"source_tool": "make"
},
"idempotency_key": "gmail-msg-18cf2a91"
}HTTP → Make a request. Set the method to POST and the body type to Raw / JSON.
Yes — one triggered by an incoming client message (posts to /api/v1/events/inbound), one triggered by your reply (posts to /api/v1/events/outbound). They run independently.
Pass idempotency_key set to the source module's own message id. A repeat call with the same key is a safe no-op and won't create a duplicate conversation event.
Yes — set channel.type per bundle (e.g. from a router), so one scenario can fan out to WhatsApp, email, or Slack events.