Events and the event log

Everything that happens to your applications and your account is an event. Each one is written to your event log, and delivered to your webhook when you subscribed to it. The log is readable as a feed, so your backend can poll it instead of running a webhook, or catch up after an outage without losing anything.

The events

Every service.* event carries service_id and application_id (the same value; service_id is the legacy name) and your external_id.

Event	When	Extra `data`
`service.approved`	The application was approved: by you in the console, by Tawked, or at once under the auto-clean mode.	`status: "active"`
`service.rejected`	Rejected, by you or by Tawked.	`status: "rejected"`, `reason` when one was given, `reason_code` when Tawked rejected it (see below)
`service.suspended`	Suspended: by you (the endpoint or the console) or by Tawked.
`service.resumed`	Switched back on: by you, or by Tawked lifting its suspension.
`service.paused`	The protection guard paused it after a spike in new destinations.	`reason: "destination_spike"`
`service.unpaused`	The pause was lifted, by you or by Tawked.
`service.review_requested`	A new name or website sent a live or rejected application back to review; a new logo does only on a rejected one.	`status: "review"`, `reason: "brand_changed"`
`service.archived`	You archived the application, from the API or the console.	`archived_at`
`service.restored`	The application came back from the archive: you restored it, or provisioned its `external_id` again.
`balance.low`	A charge took your balance from at or above your threshold to below it.	`balance_halalas`, `threshold_halalas`; no application fields

When Tawked’s review rejects an application it picks a reason from a fixed list, and service.rejected carries its code beside the sentence in reason. Branch on the code, never on the sentence, which may change wording:

`reason_code`	Meaning	Appeal
`protected_brand`	The name resembles a government body, a bank or a protected brand.	Yes
`impersonation`	The name suggests another business.	Yes
`name_website_mismatch`	The name does not match the website.	Yes
`website_unreachable`	The website does not open.	No: fix the website and send it again
`name_format`	The name’s format is not accepted.	No: edit the names
`names_differ`	The Arabic and English names differ.	No: edit the names
`logo_mismatch`	The logo is not the application’s.	Yes
`activity_not_allowed`	The activity is not allowed.	Yes
`needs_proof`	Tawked needs proof that the name is yours.	No: send the proof with the website
`other`	Another reason, explained in `reason`.	Yes

A rejection you make yourself in the console, and one made before 2026-10-04, carry no reason_code. A rejection that may be appealed can be, once, within 14 days, from your console’s Clients place; Tawked answers within two working days and the next service.approved or service.rejected tells you the outcome. The list may grow: treat an unknown code as other. And, opt-in because they come one per code, the verification events a client’s own application would get on its own webhook, with your external_id added to the data:

Event	When
`verification.verified`, `verification.failed`, `verification.expired`	A code was entered correctly, a verification failed, a code expired unused. The data is the verification as `GET /v1/verify/{id}` shows it.

A client application sends no WhatsApp, so there is no message.* event for a partner.

Subscriptions

By default every service.* event and balance.low reach your webhook; the verification events do not until you opt in. Change the set in the console under Clients → API and webhook, Webhook, Edit events, or with PUT /v1/partner/webhook:

curl -X PUT https://tawked.com/v1/partner/webhook \
  -H "Authorization: Bearer tk_partner_xxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "events": ["service.approved", "service.rejected", "service.archived", "verification.verified"] }'

An empty list delivers nothing; null resets the default set. GET /v1/partner/webhook shows the current set beside default_events and available_events. A subscription changes delivery only: lifecycle and balance events are written to the log whatever you subscribed to, while the opt-in events are written only when subscribed, since they are readable through the code log anyway.

Endpoints that existed before subscriptions did keep receiving the events they always received (service.approved, service.rejected, service.suspended, service.paused, balance.low) until you opt in to more. Nothing new reaches an existing integration on its own.

The feed

GET /v1/partner/events lists the log oldest first, up to 100 rows a page, each with the event, your external_id, the data the webhook would carry, and the delivery it produced when there was one.

curl "https://tawked.com/v1/partner/events?since=2026-09-26T00:00:00Z&limit=50" \
  -H "Authorization: Bearer tk_partner_xxxxxxxxxxxxxxxxxxxx"

{
  "data": [
    {
      "id": "0f4c9c0e-6d2b-4b8a-9c3e-7a1d2e3f4a5b",
      "event": "service.approved",
      "external_id": "store_88",
      "data": { "service_id": "c2a10f3e-8b7a-4d2e-9c1a-1a2b3c4d5e6f", "application_id": "c2a10f3e-8b7a-4d2e-9c1a-1a2b3c4d5e6f", "external_id": "store_88", "status": "active" },
      "created_at": "2026-09-26T09:00:00.000Z",
      "delivery": { "id": "6d2b4b8a-9c3e-4a5b-8f2a-0f4c9c0e7a1d", "status": "delivered", "attempts": 1, "delivered_at": "2026-09-26T09:00:01.250Z" }
    }
  ],
  "next_cursor": "eyJzZXEiOjQyfQ",
  "has_more": false
}

Resume with the cursor. next_cursor points after the last row you received, whether or not more rows exist now; keep it and pass it back as cursor on the next call. has_more says whether a page is waiting right now. An empty page answers null, so keep the cursor you had.
Start from a time. since takes an ISO 8601 date or datetime for the first call, when you have no cursor yet.
Filter with event (one event name) and application (your external_id).
Two seconds behind. Rows younger than two seconds are held back, so a cursor you save never skips a row whose sequence was taken earlier but committed later.
At least once. Treat the feed like the webhook: dedupe by the event id.
Ninety days. Events and finished deliveries older than 90 days are pruned.

The feed and the webhook carry the same events with the same data; a webhook delivery’s event header is the same name. Read the deliveries when you want to know whether a specific webhook call succeeded.

Get started

Verify

Notifications

Email

Webhooks and errors

Partners

Build with AI

Events and the event log

The events

Subscriptions

The feed

​The events

​Subscriptions

​The feed

The events

Subscriptions

The feed