Skip to content
Developers · Changelog

Release notes — Everything new in the API as they happen.

The Wthaiq API evolves continuously without disrupting your integration, and the version is pinned with a dated header Wthaiq-Version: 2026-07-01: changes non-breaking — such as a new endpoint, an optional field or an event type — ship continuously on your same version, while changes that are breaking come in a new dated version that does not apply to you until you choose to upgrade to it yourself. This page documents every change with its date and its tag.

Read the documentation
Current stable version: v1 · 2026-07-01
The pinned dated version Wthaiq-Version: 2026-07-01
AddingFixChange
Adding
ChangeAddingDiscontinued
AddingChange
Current stable version · v1
Color and type — and impact on your integration

Tag guide

Every change in the log is tagged with its color and its type, so you can read its impact on your integration at a glance.

Adding Change Fix Deprecation Security
Timeline

Versions Newest first.

The timeline starts with the public launch of API v1 on 4 October 2026, followed by its updates with their exact dates and tags.

English error messages and clearer error fields
  • AddingError messages are in English with the request header Accept-Language: en or the parameter ?lang=en; Arabic stays the default, and error codes do not change.
  • FixThe path /en/api/v1/… now works exactly like /api/v1/… , and its error messages are in English.
  • Addingupgrade_url is now a field in the errors 402 plan_required and 402 plan_expired, and verify_url is a field in the error 403 kyb_required, and max_signers is a field in the error 400 too_many_signers.
  • ChangeGET /v1/verifications/{reference} for an unknown reference returns a 404 error in the standard format with the code not_found, instead of a body that looks like a success response.
  • FixGET /v1/webhook_endpoints now returns next_cursor and accepts starting_after, so you can reach every endpoint page by page.
  • FixThe field docs in GET /v1 points to the documentation in the developer portal.
Matching the signer's name with their identity document
  • AddingAfter identity verification, we match the name on the signer's document with the name sent in the request. When they differ, signing is held until you decide, and you receive the event signer.identity_match_hold then signer.identity_match_decided after the decision.
  • AddingA new endpoint for the decision: POST /v1/signers/{id}/identity_match with the value approve or reject, plus an “Identity review” page in the developer console with a new “Identity reviewer” role.
  • AddingThe signer object carries identity.name_match with the match state and both names, and from the same page you can choose “Record the difference only” instead of holding signing.
Developer accounts and yearly plans
  • ChangeThe developer console is now a separate product with its own developer account, created from its sign-up page and not linked to Wthaiq platform accounts in sign-in, data or balances.
  • ChangeLive sending requires a paid yearly plan and a verified company; otherwise the API returns 402 plan_required or 402 plan_expired or 403 kyb_required. Test keys remain free, within daily limits.
  • ChangeEvery signer on a live request counts as one send from your annual plan balance, with a maximum of five signers per request. Once it runs out, the overage is charged to the wallet at your plan's rate, and identity verification is always charged to the wallet. If the balance isn't enough, the error returned is 402 insufficient_balance and the request is not created.
  • AddingThe API returns 403 plan_feature_unavailable when a request asks for a capability your plan does not include, with the fields feature and required_plan and upgrade_url.
  • ChangeThe endpoints GET /v1/usage and GET /v1/balance now return amounts as objects in your wallet currency, together with the plan and its prices, and no longer return the keys amount_egp and month_spent_egp and send_egp. The field cost in a session is now an object with the amount, currency and source.
  • DeprecationThe free live requests that were available before account verification have been removed; the field trial remains on older requests only.
Public launch of API v1
  • AddingSignature requests on the path POST /v1/signature_requests with their full lifecycle, and the endpoints send and cancel and reminders and download and certificate and evidence.
  • AddingTemplates through GET /v1/templates and creating a signature request from a template by passing its field values, and public verification by reference through GET /v1/verifications/{reference}.
  • AddingEmbedded signing inside your app through POST /v1/signers/{id}/signing_session and /v1/sessions, and signer identity confirmation through a specialist provider with the field require_identity and the object identity_verification.
  • AddingSigned event notifications (Webhooks) with the header Wthaiq-Signature using HMAC-SHA256, with retries at increasing intervals for up to 24 hours, including the identity review events signer.identity_in_review and signer.identity_resubmission_requested and signer.identity_declined.
  • AddingLive keys with the prefixes sk_ and pk_, and test keys with the prefixes sk_test_ and pk_test_ that charge nothing and send no message to anyone; the field livemode shows which of them created the object.
  • ChangeAll errors return in one structure, and Idempotency-Key on requests POST requests to make retries safe; the limit is 100 requests every 10 seconds, with the headers X-RateLimit-Limit and Retry-After, and every response carries Wthaiq-Request-Id.
  • AvailableOfficial SDKs: wthaiq/wthaiq-php (PHP) · wthaiq (Node.js) · wthaiq (Python) — they pin the version header by default and follow SemVer. together with the two in-app signing libraries (iOS · Android); the install commands are on the official libraries page.
Versioning policy

How we ship changes without breaking your integration.

We follow date-based versioning. The behavior of your pinned version never changes through a breaking change — you alone decide when to upgrade it.

Breaking changes

Require a new dated version

  • Removing an endpoint, a field or a value enum, or renaming it.
  • Changing the type of an existing field (for example from string to integer).
  • Adding a new required parameter (required) to an existing request.
  • Tightening validation rules so that requests previously accepted are now rejected.
  • Changing the default semantics of a response, or the order of the items in a list.

Non-breaking changes

ship continuously on your same version

  • Adding an entirely new endpoint.
  • Adding a new field Optional into a response body.
  • Adding a value enum new (handle unknown values gracefully).
  • Adding a new Webhook event type to the list.
  • Adding a new optional parameter to an existing request.
The deprecation window: We announce any deprecation in this changelog with a "Deprecation" tag, and we send the header Wthaiq-Deprecation on the responses concerned, and we keep the old behavior working for at least 6 months before removing it in a new dated version — leaving enough time to upgrade safely.

Pin the version by sending the header Wthaiq-Version with every request. If you do not send it, the last dated version pinned to your account is used (or the latest default version). The behavior of your pinned version never changes through a breaking change. Example:

pin-version.sh 
curl https://wthaiq.com/api/v1/signature_requests \
  -H "Authorization: Bearer sk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Wthaiq-Version: 2026-07-01"

# The response returns the version actually used in the header:
# Wthaiq-Version: 2026-07-01
# Wthaiq-Request-Id: req_9f2a1c
Upgrade deliberately: When you are ready to adopt a newer dated version, review its differences in this changelog, try it first with a small request on your account (there is no separate test key — the request is real and billed), then switch the value of Wthaiq-Version in production. There is no need to upgrade all at once — each integration upgrades at its own pace.
From the changelog — to the documentation

Ready to build your integration?

Start from the full API documentation, pin your dated version, and subscribe to receive every update as it ships.

Read the documentation API reference