Changelog

The changelog lists the versions of the two Wexa SDKs that are current and what changed in each.

It is for anyone who installs either SDK. 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

A clear 503 when the knowledge base is unavailable

knowledge-base-add, knowledge-base-retrieve and delete-kb-document now answer 503 with the error S8:knowledge-base-unavailable and the message knowledge base unavailable: … when the knowledge base's document store is down or rejects the platform's credential. They used to answer 502 S8:execute carrying the store's raw internal error, such as a gRPC UNAUTHENTICATED dump. Both SDKs raise it as UpstreamError with no upgrade needed. See when the knowledge base is unavailable.

Agent types, and corrected agent documentation

create-agent now explains the console's five agent types — Conversational, Task, Voice, Proxy and Interop — and how to create each one on every surface. It states what only the console can do: voice calls, the first promoted version a Proxy agent's endpoint needs, and publishing an agent for external callers.

The agent pages now also say:

• when an agent with no skill can run, on create-agent and run-agent
• that run-agent runs one agent and refuses a process flow id, and which turns session memory recalls
• what an external agent node really hands over, the one-tool rule for an MCP external agent, and how long a question from an external agent waits
• the organization agent limit and the error it gives
• which tools take a compound agent id whole, on identifiers

Corrected claims: a new agent's default model is the organization's registry default, not system_model; a process flow node has three types, not two. Known-limitation notes cover files and input_variables on run-agent and run-process-flow, and the run goal an external agent node does not pass on. The documentation tool's orchestrate topic says the same, and its tool list now names every agent tool.

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.6.0

Eight new tools since 0.5.0, taking the client from 60 to 68.

• connectWhatsApp, completeWhatsAppConnection and getWhatsAppConnection connect a WhatsApp account: the first returns a QR link to scan on the phone, the second finishes the connection the same way Finish authentication does in the console, and the third reads its status. The first two take wait to poll until the scan lands, and need the new fabric:connector.connect grant. See connect-whatsapp.
• requestApproval and getApproval let your own application raise an approval and read the decision.
• listProjects, myProjects and connectProject find the projects a user belongs to and open a separate session for another one; names() returns display names for the signed-in scope.
• graphStats and graphSubgraph read the context graph the way the console draws it.
• listExecutions lists a process flow's runs.
• Breaking: reject needs a reason, reject(approvalId, reason).

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.6.0

Eight new tools since 0.5.0, taking the client from 60 to 68.

• connect_whatsapp, complete_whatsapp_connection and get_whatsapp_connection connect a WhatsApp account: the first returns a QR link to scan on the phone, the second finishes the connection the same way Finish authentication does in the console, and the third reads its status. The first two take wait=True to poll until the scan lands, and need the new fabric:connector.connect grant. See connect-whatsapp.
• request_approval and get_approval let your own application raise an approval and read the decision.
• list_projects, my_projects and connect_project find the projects a user belongs to and open a separate session for another one; names() returns display names for the signed-in scope.
• graph_stats and graph_subgraph read the context graph the way the console draws it.
• list_executions lists a process flow's runs.
• Breaking: reject needs a reason, reject(approval_id, reason).

0.2.0

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.