tawked.com. Filter by product with the tags, or follow the RSS feed. A change that can break a working integration carries the Breaking tag.
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 forPOST and DELETE .../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.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,POSTandDELETE /v1/partner/applications/{external_id}/owner, and theservice.owner_invited,service.owner_acceptedandservice.owner_revokedevents. - 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 themessage.*events on the partner webhook.- The
ownerandwhatsappblocks of an application row, andprices.whatsapp_message_halalasandowner_invite_capsof the profile.
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.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.Image headers on WhatsApp templates
A template that opens with an image now sends: pass the image’s public link inheader.image.link. Such a template sent without it answers 422 invalid_params, where it answered 422 unsupported_template before. See Sending messages.Marketing opt-outs
A MARKETING template to a recipient who asked the application to stop its marketing answers422 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.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 and Sending messages.Tawked is now three products on one balance: Tawked Verify, Tawked Notifications and Tawked Chat. Nothing changed under /v1.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.The message log, the WhatsApp templates and the team over the Partner API, also announced in this release, were removed on 2026-10-04.
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.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.The verification lifecycle, idempotency, protection and webhooks
GET /v1/verify/{id},POST /v1/verify/{id}/resendandPOST /v1/verify/{id}/cancelcomplete the lifecycle.startaccepts anIdempotency-Keyheader, areferenceand 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.
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.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.A per-key rate limit
The/v1/verify endpoints limit each key to 120 requests per minute, and every response carries security headers.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.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 withPOST /v1/partner/services.