Changelog

What is current, and what moved to get there. The two SDKs share a version line: the TypeScript client is a port of the Python one, and the Python package remains the source of truth for behaviour, so the two numbers track each other rather than drifting apart.

Current versions

Install either with the command its own quickstart gives you:

npm install @wexa-fabric/sdk

pip install wexa

The Wexa MCP server and the REST API are not versioned as packages. The Wexa MCP server reports its own protocol version in the handshake — 2025-06-18 at the time of writing — and the REST surface is versioned in the path, as /v1.

Unreleased

One approval module and one Inbox

Every approval in Wexa now goes through one approval module and is decided in one Inbox, in the console under Actions → Approvals. That covers tool calls held from the SDKs, the REST API and the Wexa MCP server, as well as flow previews, anomalies, analytics and governance gates, permission requests, capability activations, marketplace submissions, policy revisions and proactive cards. Your own application can raise an approval with the new request-approval tool and read the decision with get-approval. Deciding an approval resumes or stops the paused work. Approval ids are now ar_ followed by 24 hexadecimal characters, and resume tokens start with hrt_. See approvals.

Breaking: consequential writes wait for approval by default

Every project now holds consequential writes made with an API key or an SDK session until a person approves them, admin API keys included. Newly held: insert-table-rows, update-table-row, create-table, rename-table, set-triggers and run-connector-action. A held call returns 202 and ApprovalRequired with an approval id and a resume token. Actions taken by a person in the console are not held. To turn this off for a project, a project admin clears Hold consequential writes from API keys and SDK sessions for approval in Settings → Projects.

SDK wait

wait_for_approval in Python and waitForApproval in TypeScript end on the first final status of the approval. approved resumes the call. rejected, expired, overdue and consumed raise or throw ApprovalError.

Removed

• The switch that let a requester approve their own request everywhere is gone. A requester may approve their own request only in a project they administer.
• Approvals are no longer held in the gateway's memory. They are stored, and they survive a restart.

TypeScript SDK

0.2.3

Documentation and comments only; no change in behaviour.

• Every source citation re-anchored on a symbol name rather than a line number. All of them had gone stale, and two named a different constant than they claimed, after entries were added to the Python tool table and shifted every line below.
• Removed from the shipped type declarations: bookkeeping about the port, and three references to a document that is not published.
• Where the shipped types noted that a grant requirement was undocumented, they now say what to do about it — call the documentation tool with topic: 'governance' to list the grants you hold.

0.2.2

The repository field pointed at a private repository, so the link on the registry page resolved to nothing. Removed; homepage now points at the product site.

0.2.1

Republished from 0.2.0, which was taken on the registry but not servable. No code changes.

0.2.0 — withdrawn

The first release, and a port of the Python client at the same version.

• The Fabric client: bearer authentication, endpoint discovery from the gateway's connection-info endpoint, and the governed lifecycle's typed errors.
• Every gateway tool as a typed method. Argument types are taken from each tool's own argument definition in the gateway rather than hand-written, because the Python client forwards arbitrary keyword arguments and so has no field list of its own to copy.
• resume(tool, token) for the approval round trip, and waitForApproval for callers that can block.
• Thirteen error classes with the Python inheritance chain preserved — that chain is the retry policy. A timeout retries as an upstream fault; a configuration error does not, despite its status code.
• Opt-in retries honouring Retry-After, with full jitter capped at the quota window.
• AbortSignal support on every method, composing with the client's own timeout, and cancelling a retry backoff or an approval poll as well as a request.
• close(), and Symbol.asyncDispose for await using.
• A dual ESM and CommonJS build with no runtime dependencies, for Node 18 and newer and for browsers.

Python SDK

0.2.0

The current release, and the reference implementation both clients are measured against. One module, standard library only, no dependencies to conflict with yours. Requires Python 3.9 or newer.

Every call runs the gateway's governed lifecycle, and a refusal names the stage that refused it — S2:resolve-scope, S4:validate-input, S5:policy, S8:execute — so you can tell a credential problem from a payload problem from a retry problem without guessing.

Divergences between the two clients

The TypeScript client is a port, not a translation, and two differences change how you write code.

• It is asynchronous only. Node has no synchronous HTTP, so every method returns a promise where the Python method returns a value.
• Constructing it does not reach the network. A missing workspace or credential still throws synchronously, but discovering the gateway's base URL is deferred to the first call, because a constructor cannot await. The Python client discovers it eagerly, which is why fabric.base is populated immediately there and only after the first call in TypeScript.

Where to go next