> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tawked.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Changes to the Tawked API, its webhooks and its integrations, newest first, dated by the day they reached production. Breaking changes are tagged.

Every change a developer can notice, dated by the day it went live on `tawked.com`. Filter by product with the tags, or follow the [RSS feed](https://docs.tawked.com/changelog/rss.xml). A change that can break a working integration carries the **Breaking** tag.

<Update label="2026-10-05" description="Review" tags={["Verify", "Partner API"]}>
  ## A logo no longer sends a live application back to review

  The logo never reaches a message, so Tawked no longer reviews it. Uploading or removing a logo on an active application keeps it active, and its codes keep sending. This holds for the console and for [`POST`](/api-reference/partner/upload-the-logo) and [`DELETE .../logo`](/api-reference/partner/remove-the-logo) on the Partner API, which no longer fire `service.review_requested` for a live application.

  A rejected application is the one exception: a new logo, or its removal, returns it to review, since the rejection may have been about the logo. Names and the website are reviewed as before.
</Update>

<Update label="2026-10-04" description="Release 1.2.0" tags={["Breaking", "Partner API", "Verify", "Notifications", "Webhooks"]}>
  ## Breaking: a partner's client applications are Verify only

  A client application a partner provisions is now Tawked Verify only, and it stays the partner's. Everything about Verify on the Partner API answers byte for byte as before. Removed:

  * The owner hand-over: `GET`, `POST` and `DELETE /v1/partner/applications/{external_id}/owner`, and the `service.owner_invited`, `service.owner_accepted` and `service.owner_revoked` events.
  * WhatsApp on client applications: `GET .../{external_id}/whatsapp`, the templates under `.../whatsapp/templates` (list, read, create, update, delete) and the team under `.../whatsapp/team` (list, add, remove).
  * `GET /v1/partner/messages`, and the `message.*` events on the partner webhook.
  * The `owner` and `whatsapp` blocks of an application row, and `prices.whatsapp_message_halalas` and `owner_invite_caps` of the profile.

  A partner's own applications are managed in the console, like any other account's, and send WhatsApp with their own application keys. See [Partner API](/partners/overview).

  ## Reasons on rejections

  `service.rejected` carries a `reason_code` when Tawked rejects an application, from a fixed list, with whether the rejection may be appealed. See [Partner events](/partners/events).

  ## Key access by product

  A key has full access, or custom access per product: `verify:check`, `verify:send`, `notifications:read`, `notifications:send`. A call outside the key's access answers `403 insufficient_scope`, with a `WWW-Authenticate` header that names the scope it needs. Existing keys keep exactly what they could do. See [Key access](/authentication#key-access).

  ## Image headers on WhatsApp templates

  A template that opens with an image now sends: pass the image's public link in `header.image.link`. Such a template sent without it answers `422 invalid_params`, where it answered `422 unsupported_template` before. See [Sending messages](/whatsapp/messages#image-headers).

  ## Marketing opt-outs

  A MARKETING template to a recipient who asked the application to stop its marketing answers `422 consent_opted_out`. Nothing is sent or charged. Utility and authentication templates still reach them.

  ## Webhook test events and sending again

  **Send a test event** on an application's Webhooks page delivers a signed sample whose envelope carries `"test": true`. A failed delivery can be sent again from the **Delivery log**, so handlers should be idempotent on `data.id` and the event name. See [Webhooks](/webhooks).
</Update>

<Update label="2026-09-30" description="Templates" tags={["Notifications"]}>
  ## Three template categories and authentication templates

  Templates come in Meta's three categories: utility, marketing and authentication. An authentication template sends a one-time code from your own WhatsApp number with one value, `"params": { "code": "482913" }`, of 4 to 15 letters or digits. Tawked stores the code masked. See [Templates](/whatsapp/templates) and [Sending messages](/whatsapp/messages#authentication-templates).

  Tawked is now three products on one balance: Tawked Verify, Tawked Notifications and Tawked Chat. Nothing changed under `/v1`.
</Update>

<Update label="2026-09-27" description="Partner API" tags={["Partner API"]}>
  ## The Partner API grows

  A partner sandbox key, `tk_partner_test_`; an `Idempotency-Key` on every write; bulk provisioning; archiving and restoring; a verification log; and an event feed with webhooks you subscribe to by event. See [Partner API](/partners/overview).

  <Note>
    The message log, the WhatsApp templates and the team over the Partner API, also announced in this release, were removed on 2026-10-04.
  </Note>
</Update>

<Update label="2026-09-11" description="Notifications" tags={["Notifications"]}>
  ## Connect your own WhatsApp number

  Connect your WhatsApp Business Account from the console through Meta's Embedded Signup. The account stays yours, and Meta bills you directly for its messages.
</Update>

<Update label="2026-09-06" description="Notifications" tags={["Notifications", "Webhooks"]}>
  ## WhatsApp template messages over the API

  `POST /v1/whatsapp/messages` sends an approved template from your application's number with the same key, and its statuses reach your webhook as signed `message.*` events.
</Update>

<Update label="2026-09-04" description="Verify" tags={["Verify", "Webhooks"]}>
  ## The verification lifecycle, idempotency, protection and webhooks

  * `GET /v1/verify/{id}`, `POST /v1/verify/{id}/resend` and `POST /v1/verify/{id}/cancel` complete the lifecycle.
  * `start` accepts an `Idempotency-Key` header, a `reference` and autofill-ready messages.
  * Per-application spend caps and per-IP limits guard against SMS pumping.
  * Keys can carry an expiry and an IP allowlist, and a check-only key could be created. Check-only keys became the custom access of 2026-10-04.
  * Each application can receive signed webhooks for verified, failed and expired verifications.
</Update>

<Update label="2026-08-16" description="Partner API" tags={["Partner API", "Webhooks"]}>
  ## Partner webhooks

  `service.approved`, `service.rejected`, `service.suspended` and `balance.low` are delivered to the partner's webhook, signed with its secret. The reference gained `GET /v1/partner/services` and `POST .../resume`.
</Update>

<Update label="2026-08-15" description="Verify" tags={["Breaking", "Verify"]}>
  ## Verification over SMS only

  The email verification channel and the old notifications product stopped. `POST /v1/messages` answers `410 product_retired`. Account data and balances were untouched.
</Update>

<Update label="2026-08-11" description="Verify" tags={["Verify"]}>
  ## A per-key rate limit

  The `/v1/verify` endpoints limit each key to 120 requests per minute, and every response carries security headers.
</Update>

<Update label="2026-08-10" description="Verify" tags={["Verify"]}>
  ## The sandbox

  `tk_test_` keys call the same endpoints with the same shapes before the application is approved. Codes are real, stamped `[TEST]`, and reach the account owner's phone only. Today you create the test key yourself, under **Application settings → API keys**. See [Testing and the sandbox](/sandbox).
</Update>

<Update label="2026-08-07" description="Verify" tags={["Verify", "Partner API"]}>
  ## Verify settings per application, and the partner platform

  Code length from 4 to 8 digits, a lifetime from 1 to 15 minutes, 1 to 5 attempts and an hourly cap per number, set in the console only, so a leaked key cannot weaken them.

  Platforms got one account that creates an application per merchant with `POST /v1/partner/services`.
</Update>

<Update label="2026-06-08" description="Platform" tags={["Verify"]}>
  ## Several applications on one account

  One account holds several applications, each with its own keys and logs, sharing one balance.
</Update>

<Update label="2026-05-29" description="Launch" tags={["Verify"]}>
  ## Tawked Verify

  `POST /v1/verify/start` and `POST /v1/verify/check`, API keys and a prepaid balance.
</Update>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.