Changelog

Every customer-visible change to the API and the portal, newest first.

Versioning and deprecation policy

The API is versioned in the URL: every endpoint lives under /v1.

Additive changes ship without prior notice. New endpoints, new optional request parameters, new fields inside existing responses, new values in existing lists and new error codes for new failure modes can appear at any time. Your integration must therefore ignore response fields it does not recognise rather than fail on them.

Nothing is removed or repurposed without 90 days' notice. No response field, request parameter, endpoint or error code inside /v1 will be removed, renamed or given a new meaning without a dated deprecation entry published on this page at least 90 days beforehand. The meaning of an existing error code will not change either.

Breaking changes ship as a new version prefix. When a change cannot be made additively it goes to a new prefix, and /v1 keeps working for the notice period announced here.

2026-08-15 — Official PHP and Node clients

Two hand-written API clients are now published:

composer require whatsdev/whatsdev-php
npm install @whatsdev/sdk

Both cover the endpoints an integration touches daily and reach the rest through a generic request() method. Each carries a typed exception per error code, attaches an Idempotency-Key to every send so a dropped connection cannot deliver twice, iterates paginated lists, exposes the remaining-quota headers on send results, and verifies webhook signatures in constant time. Neither has any runtime dependency; the PHP package auto-registers a Laravel facade when Laravel is present.

Nothing about the API changed — these are clients for the surface already documented.

2026-08 — Your data: export, deletion and retention

Export a copy of your data

• New in the portal. Your profile page can now build a zip archive of the account: account and subscription details, users, messages, contacts and their custom fields, lists, scheduled messages, campaigns, templates, suppressed numbers, sessions, webhook endpoints, payments and API-key metadata, as CSV files with a manifest.json that names every category left out of the archive and why.
• It carries no credential. An API key exists only as an irreversible hash, and webhook signing secrets, session proxy credentials and password hashes are never exported.
• One archive every 24 hours. You are notified when it is ready, it is downloadable only by a signed-in user of that same account and never from a public link, and it is deleted 7 days after it is produced.

Delete your account

• New in the portal. You can close the account yourself, from the same page.
• The moment you confirm, access ends: every API key is revoked, every WhatsApp number is disconnected and handed back, and every pending scheduled message and running campaign is cancelled. None of that is restored if you change your mind.
• Everything else the account holds, stored files included, is erased permanently 14 days later. Until then you can cancel the request from the portal and the account is reopened.
• Payment records are kept in anonymised form for accounting: they are detached from the account and stripped of the fields that could name it, and cannot be traced back to it afterwards.

Sandbox retention

• Sandbox sessions are deleted once they pass the sandbox retention window, and the messages that belong to them are deleted with them. It is a session age limit, not a blanket age limit on sandbox data: a sandbox session you keep alive keeps its messages.

2026-08 — Sandbox and cursor pagination

Sandbox (test mode)

• New accounts are issued a test API key at signup. A test key needs no active subscription and carries its own rate-limit budget, separate from your plan's.
• Sandbox sessions run against a simulated WhatsApp. They connect on their own, take no slot from your plan's session allowance, and are never attached to a real WhatsApp account.
• Sends made with a test key go through the ordinary send endpoint and return the ordinary response, but never reach WhatsApp and never count against your plan's message quota. A separate daily sandbox limit applies to them instead.
• New endpoint: POST /v1/sandbox/inbound injects a simulated inbound message through the same pipeline a real one travels, so your webhook receiver, its signature check and your auto-replies can be exercised end to end without asking anyone to message you.
• Test and live are kept apart in both directions: a test key is refused on a live session and a live key is refused on a sandbox session, and GET /v1/sessions returns only the sessions matching the calling key's mode.
• A simulated opt-out ("إيقاف") is detected and answered with the same confirmation reply, which travels the simulated transport and so reaches nobody. The one difference is that it is never written to your real suppression list: that list is account-wide rather than per-session, so a simulated opt-out must never block a real number from your live sending. For the same reason a test key cannot change that list (POST and DELETE /v1/suppressions), though it may read it.
• A webhook created with a test key must be scoped to a sandbox session, so whatsapp_session_id is required with one: a webhook with no session is account-wide and receives your live sessions' events, bodies and numbers included, which no test key may reach.
• Sandbox sessions — and the messages that belong to them — are deleted once they pass the sandbox retention window. Nothing outside the sandbox is touched by that sweep.

Cursor pagination

• ?cursor= is now accepted on the session-message, scheduled-message, contact, bulk-operation, bulk-recipient and webhook-delivery lists.
• It is opt-in and additive. Leave cursor off the request and page-based pagination is unchanged: same ordering, same meta, same links.
• It exists for traversal stability, not for speed. Walking a list by page number while new rows are still arriving repeats some rows and skips others; a cursor walk does not.
• In cursor mode the response carries meta.next_cursor and meta.prev_cursor in place of meta.total, meta.current_page, meta.last_page, meta.from and meta.to, and links.first and links.last are null. Follow links.next, which preserves the filters and per_page you sent.

Portal

• The message list hides sandbox messages by default and offers a filter to show them, so test traffic never clutters the real inbox.