Skip to content
Whats91

How Whats91 API versions are numbered, mounted, and supported, and how to choose the right version for an integration.

API Versioning

Summary

How Whats91 API versions are numbered, mounted, and supported, and how to choose the right version for an integration.

Prerequisites

  • A Whats91 account

Whats91 versions the public API in the URL path. A version is a frozen contract: once a version is published, its routes, request fields, and response shapes do not change in a breaking way. New behaviour ships as a new version.

Available Versions

VersionBase URLStatusUse for
v2https://graph.whats91.com/api/v2Stable, defaultThe default choice. Complete messaging, template, webhook, report, billing, order, and automation surface.
v3https://graph.whats91.com/api/v3StableEverything in v2, plus Direct Send, template source attribution, and send-route reporting.
v1https://graph.whats91.com/api/v1LegacyExisting integrations only. Do not build new integrations on v1.

Note

Use the version switcher in the header to move this documentation between versions. Navigation, endpoints, request and response examples, guides, and reference content all follow the selected version.

Mount Paths

The canonical mount is /api/{version}. Some older versions also answer on an unprefixed twin path, but the twin paths expose a reduced surface and should not be used for new work.

VersionCanonical mountTwin mountTwin mount surface
v1/api/v1/v1Full v1 surface.
v2/api/v2/v2Send and chat routes only. Templates, webhooks, reports, billing, chatbots, contact books, blacklist, custom boards, CRM, orders, and integrations all return 404 NOT_FOUND.
v3/api/v3NoneThere is no /v3 mount. Only /api/v3 is routed.

Warning

Always call /api/v3. Requests to an unprefixed twin path may return 404 NOT_FOUND for endpoint families that are only exposed on the canonical mount.

What a Version Guarantees

  • Routes are not removed or renamed within a published version.
  • Required request fields are not added within a published version.
  • Response fields are not removed or retyped within a published version.
  • New optional request fields and new response fields can be added; treat unknown response fields as additive and ignore them.
  • Error codes are stable identifiers; error messages are human-readable and can be reworded.

Choosing a Version

  1. Building something new and you do not need Direct Send: use v2. It is the default and the widest-deployed surface.
  2. You need Direct Send, template source attribution, or send-route reporting: use v3.
  3. You are on v1: plan a move to v2. v1 remains available for existing integrations but receives no new capability.

Tip

v3 is a superset of v2. Moving from v2 to v3 requires no request changes; see the migration guide.

Related Documentation