SDK to API parity matrix

Use this page to find the exact modulex-js and modulex-python method for any backend REST route — and to see, at a glance, where the two SDKs diverge in coverage, naming, or behavior. It is the single source of truth for “which method calls this endpoint” and “does this endpoint have a method at all.” Every row traces to a backend router and a per-SDK method. Where the SDKs disagree, both sides are shown. For the operation-level request and response detail, follow the route into the Endpoints reference; for the SDK client setup, see the JavaScript SDK and Python SDK pages.

This matrix covers method-to-route coverage and cross-SDK naming and behavior divergence. Per-route status codes and error envelopes live in Errors and status codes; SSE frame shapes live in SSE run streaming; credit gating lives in Usage gating and limits.

How to read this page

The SDKs are thin clients over the backend REST surface. A method calls base_url + path and returns the response. Three rules make the mapping predictable, and three structural facts make it diverge. The predictable rules:

Method names follow the route, with casing per language. JavaScript uses camelCase verbs (setDefault, getState); Python uses snake_case (set_default, get_state). The naming divergences section lists the handful of cases where the names differ by more than casing.
Auth is identical in both SDKs. Every request sends Authorization: Bearer mx_live_… plus X-Organization-ID when an organization is resolved. See Authentication. There is no X-Authorization header anywhere — neither SDK sends it and the backend does not read it.
One backend route can map to differently-grouped SDK methods. For example, GET /workflow-runs is workflowRuns.list in JavaScript but executions.list_runs in Python.

The structural divergences — covered in detail below — are: the JavaScript SDK returns raw, un-modeled responses while Python returns typed Pydantic models; the subscriptions resource exists only in Python; and environment-variable fallback exists only in Python.

The three structural divergences

These three facts are load-bearing for any side-by-side SDK code. Read them before the matrix.

Responses: JS returns raw snake_case, Python returns typed models

The JavaScript SDK takes camelCase parameters and converts them to snake_case before sending (convertKeysToSnakeCase), but it does not convert responses back — it returns the parsed JSON verbatim, so response fields stay snake_case (run_id, created_at). A JS call is effectively response.json() as T: there is no runtime model, no validation, and no field renaming on the way out. This is the JS-only “raw response” behavior — camelCase in, snake_case out, asymmetric by design.The Python SDK is snake_case end to end. Requests are built as snake_case dicts verbatim, and responses are parsed into Pydantic models (configured extra="allow", with a dict-compatible shim). Field names are stable in both directions.

JavaScript

// camelCase params in, snake_case fields out
const wf = await client.workflows.create({ name: "Lead triage", isActive: true });
console.log(wf.created_at); // snake_case on the response — NOT createdAt

Python

# snake_case both ways, typed model out
wf = await client.workflows.create(name="Lead triage", is_active=True)
print(wf.created_at)  # typed attribute on a Pydantic model

There are two casing traps inside the JS request body itself: DSL config fields are already snake_case in TypeScript (integration_name, system_prompt), so the converter is a no-op on them, and UpdateChatParams.is_private is snake_case in the TS parameter surface — both break the otherwise-camelCase JS convention.

subscriptions resource: Python-only

modulex-python exposes a full client.subscriptions resource (four methods). modulex-js has no subscriptions resource and no subscriptions methods — there is no subscriptions.ts in the JS SDK at all. This is a real parity gap, not a naming difference. See the subscriptions table and Subscriptions and Stripe.The JavaScript SDK surfaces billing only indirectly: organizations.invitePreview returns a prorated seat cost, and the dashboard analytics payloads carry subscription and current_month_credit_usage fields. If you need plan, billing, checkout, or customer-portal calls from JavaScript, call the REST routes directly with fetch.

Environment-variable fallback: Python YES, JS NO

The Python client reads MODULEX_API_KEY, MODULEX_BASE_URL, and MODULEX_ORGANIZATION_ID from the environment when the corresponding argument is omitted. The JavaScript client reads none of them — apiKey must be passed to the constructor or it throws, and baseUrl / organizationId are constructor-only.

Setting	modulex-js	modulex-python
API key	constructor `apiKey` only; throws if missing	`api_key=` arg or `MODULEX_API_KEY`; `ValueError` if neither
Base URL	constructor `baseUrl` only; default `https://api.modulex.dev`	`base_url=` arg or `MODULEX_BASE_URL` or default
Organization ID	constructor `organizationId` only	`organization_id=` arg or `MODULEX_ORGANIZATION_ID`

JavaScript

// JS: no env fallback — apiKey is required in the constructor
import { Modulex } from "modulex-js";

const client = new Modulex({
  apiKey: "mx_live_xxx",
  organizationId: "org_xxx",
});

Python

# Python: omit args to fall back to MODULEX_API_KEY / MODULEX_BASE_URL / MODULEX_ORGANIZATION_ID
from modulex import Modulex

client = Modulex()  # reads the environment

The JavaScript README shows process.env.MODULEX_API_KEY in example code, but that is caller code, not SDK behavior. timeout, max_retries, and default_headers have no environment fallback in either SDK.

Header divergences (the small ones)

The auth and org headers are identical across both SDKs. Only two header behaviors differ:

Header	modulex-js	modulex-python	Backend
`Authorization: Bearer`	sent	sent	required (or alternative `X-API-KEY`)
`X-Organization-ID`	sent when org resolves	sent when org resolves	read; `400` if required and missing
`User-Agent`	not sent	`modulex-python/<version>`	not significant
`Idempotency-Key`	never sent by any method	sent when you pass `idempotency_key=` on a mutating call	see the note below

Idempotency-Key does not de-duplicate runs. Python plumbs an idempotency_key argument through to the Idempotency-Key header, but POST /workflows/run assigns its own run_id, so passing it does not prevent a duplicate run. JavaScript does not send the header. Do not rely on Idempotency-Key to make executions.run safe to retry; see Errors and retries.

Resource-group coverage

Both SDKs advertise 17 resource groups, but the sets differ by one: JavaScript lacks subscriptions. Two more groups are structured differently:

Resource group	modulex-js	modulex-python	Note
Run history	two groups: `executions` (run/listen/resume/cancel/getState) + `workflowRuns` (list/get history)	one group: `executions`, folding history in as `list_runs` / `iter_runs` / `get_run`	same backend routes, different grouping
`subscriptions`	absent	present (4 methods)	Python-only parity gap
`system`	2 methods (no `health`)	3 methods (includes `health`)	JS-only gap on `GET /system/health`

Per-resource method counts:

Resource	JS	Python
auth	6	6
workflows	8	8
executions	5	8
workflowRuns	2	— (folded into executions)
deployments	6	6
schedules	11	11
chats	6	6
credentials	17	15 + 1 SSE factory
integrations	8	8
knowledge	19	19
organizations	12	11
apiKeys	4	4
dashboard	5	5
notifications	2	2
composer	11	11
assistant	8	8
system	2	3
subscriptions	0	4

Two count differences are tally artifacts, not coverage gaps. The credentials sets are equivalent — Python counts its sync SSE factory (bulk_modulex_keys_stream) separately, so it reads “15 + 1” against JS’s “17”. The organizations sets cover the same 11 routes; the JS note tallies 12. Treat both rows as full parity by route. The open question on the organizations tally is tracked in Open questions.

The route-to-method matrix

Legend: a check means the SDK has a method for that route; a cross means it does not. Paths are backend-relative — the SDK calls base_url + path. Where a method name differs by more than casing, the cell shows the exact name.

auth

Route	modulex-js	modulex-python
`GET /auth/me`	`auth.me`	`auth.me`
`GET /auth/me/organizations`	`auth.organizations`	`auth.organizations`
`GET /auth/invitations/my`	`auth.invitations`	`auth.invitations`
`POST /auth/invitations/{id}/accept`	`auth.acceptInvitation`	`auth.accept_invitation`
`POST /auth/invitations/{id}/reject`	`auth.rejectInvitation`	`auth.reject_invitation`
`POST /auth/organizations/leave`	`auth.leaveOrganization`	`auth.leave_organization`

POST /auth/organizations/leave requires X-Organization-ID.

workflows (CRUD and builder)

Route	modulex-js	modulex-python
`POST /workflows` (201)	`workflows.create`	`workflows.create`
`GET /workflows`	`workflows.list` + `workflows.listAll`	`workflows.list` + `workflows.list_all`
`GET /workflows/{id}`	`workflows.get`	`workflows.get`
`PUT /workflows/{id}`	`workflows.update`	`workflows.update`
`DELETE /workflows/{id}`	`workflows.delete`	`workflows.delete`
`GET /workflows/builder/details`	`workflows.builderDetails`	`workflows.builder_details`
`GET /workflows/{id}/changes` (SSE)	`workflows.listenChanges`	`workflows.listen_changes`

workflows.create, update, and delete require an owner or admin role. DELETE /workflows/{id} is a hard delete. listAll / list_all are auto-paginators over the same GET /workflows route, not separate endpoints.

executions (run, state, resume, cancel, listen)

These routes live under the /workflows router; on the SDK side they are executions.*.

Route	modulex-js	modulex-python
`POST /workflows/run`	`executions.run`	`executions.run`
`GET /workflows/state/{threadId}`	`executions.getState`	`executions.get_state`
`POST /workflows/resume/{threadId}`	`executions.resume`	`executions.resume`
`POST /workflows/cancel/{runId}`	`executions.cancel`	`executions.cancel`
`GET /workflows/listen/{runId}` (SSE)	`executions.listen`	`executions.listen`

The legacy LLM-only mode of POST /workflows/run returns 410 Gone; use assistant.chat for agentic chat. getState / get_state return 404 (not 403) when you do not own the thread.

Three distinct “run id” identities. Do not assume one identifier across these calls. The per-execution run_id is what SSE, status, and history use; a new run_id is minted on every agent resume. The durable run_id keys the run record. The id field (returned by list/get) is a third identifier — and it, not the execution run_id, is what workflowRuns.get / get_run take. See Workflows and runs.

workflow-runs (durable history)

Route	modulex-js	modulex-python
`GET /workflow-runs`	`workflowRuns.list`	`executions.list_runs` + `executions.iter_runs`
`GET /workflow-runs/{runPk}`	`workflowRuns.get`	`executions.get_run`

This is the clearest grouping divergence: JavaScript exposes a separate workflowRuns resource; Python folds run history into executions. {runPk} is the run record’s id (returned by list/get), not the execution run_id. iter_runs is a Python-only offset auto-paginator over GET /workflow-runs.

deployments

Route	modulex-js	modulex-python
`POST /workflows/{id}/deploy`	`deployments.create`	`deployments.create`
`GET /workflows/{id}/deployments`	`deployments.list`	`deployments.list`
`GET /workflows/{id}/deployments/{depId}`	`deployments.get`	`deployments.get`
`PUT /workflows/{id}/deployments/{depId}/activate`	`deployments.activate`	`deployments.activate`
`DELETE /workflows/{id}/deployments/live`	`deployments.deactivate`	`deployments.deactivate`
`DELETE /workflows/{id}/deployments/{depId}`	`deployments.delete`	`deployments.delete`

List items omit workflow_id and description. DeactivateDeploymentResponse.previous_live_deployment_id is optional in both SDKs (omitted on a no-op).

schedules

Route	modulex-js	modulex-python
`POST /schedules`	`schedules.create`	`schedules.create`
`GET /schedules`	`schedules.list`	`schedules.list`
`GET /schedules/{id}`	`schedules.get`	`schedules.get`
`PUT /schedules/{id}`	`schedules.update`	`schedules.update`
`DELETE /schedules/{id}`	`schedules.delete`	`schedules.delete`
`POST /schedules/{id}/pause`	`schedules.pause`	`schedules.pause`
`POST /schedules/{id}/resume`	`schedules.resume`	`schedules.resume`
`GET /schedules/{id}/runs`	`schedules.runs`	`schedules.list_runs`
`GET /schedules/{id}/runs/stats`	`schedules.runStats`	`schedules.run_stats`
`GET /schedules/{id}/runs/{runId}`	`schedules.getRun`	`schedules.get_run`
`POST /schedules/{id}/runs/{runId}/retry`	`schedules.retryRun`	`schedules.retry_run`
`POST /schedules/admin/trigger-tick`	—	—

POST /schedules requires a live deployment. The admin tick route (include_in_schema=False) has no SDK method in either SDK. The exact response keys of retryRun / retry_run are an open question.

composer

Route	modulex-js	modulex-python
`POST /composer/chat`	`composer.chat`	`composer.chat`
`GET /composer/chats`	`composer.list`	`composer.list`
`GET /composer/chat/{id}`	`composer.get`	`composer.get`
`GET /composer/chat/{id}/listen/{runId}` (SSE)	`composer.listen`	`composer.listen`
`POST /composer/chat/{id}/resume`	`composer.resume`	`composer.resume`
`PATCH /composer/chat/{id}/focus`	`composer.focus`	`composer.set_focus`
`POST /composer/chat/{id}/save`	`composer.save`	`composer.save`
`POST /composer/chat/{id}/revert`	`composer.revert`	`composer.revert`
`DELETE /composer/chat/{id}`	`composer.delete`	`composer.delete`
`GET /composer/chat/{id}/status`	`composer.status`	`composer.status`
`POST /composer/chat/{id}/cancel`	`composer.cancel`	`composer.cancel`

POST /composer/chat returns 409 if a HITL prompt is pending, and 402 / 403 / 429 from the billing gate. resume mints a new run_id; its llm parameter is optional at the type level but required in production (the backend returns 400 without it). The focus / set_focus name difference is intentional.

assistant

Route	modulex-js	modulex-python
`POST /assistant/chat`	`assistant.chat`	`assistant.chat`
`GET /assistant/chats`	`assistant.list`	`assistant.list`
`GET /assistant/chat/{id}`	`assistant.get`	`assistant.get`
`GET /assistant/chat/{id}/listen/{runId}` (SSE)	`assistant.listen`	`assistant.listen`
`POST /assistant/chat/{id}/resume`	`assistant.resume`	`assistant.resume`
`GET /assistant/chat/{id}/status`	`assistant.status`	`assistant.status`
`POST /assistant/chat/{id}/cancel`	`assistant.cancel`	`assistant.cancel`
`DELETE /assistant/chat/{id}`	`assistant.delete`	`assistant.delete`

POST /assistant/chat returns 409 on a pending HITL prompt or a run already in progress, plus 402 / 403 / 429 from the billing gate. Unlike composer, assistant.resume’s llm parameter is required at the type level in both SDKs. There is no assistant rename route on the backend (PATCH /assistant/chat/{id} / .../title does not exist) — this is an unbuilt route, not an SDK gap, so no method references it. See Assistant permissions and limits.

chats

Route	modulex-js	modulex-python
`GET /chats`	`chats.list`	`chats.list`
`GET /chats/stream` (SSE)	`chats.stream`	`chats.stream`
`GET /chats/{id}`	`chats.get`	`chats.get`
`GET /chats/{id}/messages`	`chats.messages`	`chats.messages`
`PATCH /chats/{id}`	`chats.update`	`chats.update`
`DELETE /chats/{id}`	`chats.delete`	`chats.delete`

chats.list groups by folder with no pagination. chats.messages uses offset/limit, and its body omits total / has_next despite the docstring. chats.delete is a soft delete with no permanent flag (unlike composer/assistant delete). There is no POST /chats route or method — chats are created implicitly by execution, so this is not a gap.

credentials

Route	modulex-js	modulex-python
`GET /credentials`	`credentials.list`	`credentials.list`
`GET /credentials/{id}`	`credentials.get`	`credentials.get`
`POST /credentials` (201)	`credentials.create`	`credentials.create`
`PUT /credentials/{id}`	`credentials.update`	`credentials.update`
`DELETE /credentials/{id}` (204)	`credentials.delete`	`credentials.delete`
`POST /credentials/{id}/set-default`	`credentials.setDefault`	`credentials.set_default`
`POST /credentials/test-temporary`	`credentials.testTemporary`	`credentials.test_temporary`
`POST /credentials/{id}/test`	`credentials.test`	`credentials.test`
`GET /credentials/{id}/usage`	`credentials.usage`	`credentials.usage`
`GET /credentials/{id}/audit`	`credentials.audit`	`credentials.audit`
`POST /credentials/oauth2/initiate`	`credentials.initiateOAuth2`	`credentials.initiate_oauth2`
`POST /credentials/{id}/oauth2/refresh`	`credentials.refreshOAuth2`	`credentials.refresh_oauth2`
`GET /credentials/oauth2/callback`	—	—
`POST /credentials/mcp-server`	`credentials.mcpServer`	`credentials.create_mcp_server`
`POST /credentials/{id}/refresh-discovery`	`credentials.refreshDiscovery`	`credentials.refresh_mcp_discovery`
`GET /credentials/{id}/mcp-tools`	`credentials.mcpTools`	`credentials.mcp_tools`
`POST /credentials/bulk-modulex-keys/stream` (SSE)	`credentials.bulkModulexKeys`	`credentials.bulk_modulex_keys_stream`

GET /credentials/oauth2/callback is a browser redirect target and has no SDK method by design. credentials.list returns a discriminated grouped/flat union in JavaScript but raw Any in Python (the backend types it Dict[str, Any]). The JS MCPServerCredentialResponse omits updated_at, integration_type, last_used_at, and expires_at versus the full CredentialResponse. bulkModulexKeys / bulk_modulex_keys_stream is a sync SSE factory on both sides.

The SDK credentials.refreshOAuth2 / refresh_oauth2 methods exist and map to a real backend route, but the app’s “refresh OAuth2” flow is a known limitation — the UI’s BFF route is missing. When an OAuth credential expires, reconnect it rather than relying on an in-app refresh.

integrations

Route	modulex-js	modulex-python
`GET /integrations/browse`	`integrations.browse`	`integrations.browse`
`GET /integrations/tools`	`integrations.tools`	`integrations.tools`
`GET /integrations/tools/{name}`	`integrations.tool`	`integrations.tool_detail`
`GET /integrations/llm-providers`	`integrations.llmProviders`	`integrations.llm_providers`
`GET /integrations/llm-providers/{name}`	`integrations.llmProvider`	`integrations.llm_provider_detail`
`GET /integrations/knowledge-providers`	`integrations.knowledgeProviders`	`integrations.knowledge_providers`
`GET /integrations/knowledge-providers/{name}`	`integrations.knowledgeProvider`	`integrations.knowledge_provider_detail`
`GET /integrations/{name}`	`integrations.get`	`integrations.get`

GET /integrations/tools is admin-gated (organization_admin_required). Several detail methods carry a name difference (tool / tool_detail, and so on). See the Integrations overview.

knowledge-bases

Route	modulex-js	modulex-python
`GET /knowledge-bases`	`knowledge.list`	`knowledge.list`
`POST /knowledge-bases` (201)	`knowledge.create`	`knowledge.create`
`GET /knowledge-bases/stats`	`knowledge.stats`	`knowledge.stats`
`GET /knowledge-bases/{id}`	`knowledge.get`	`knowledge.get`
`PUT /knowledge-bases/{id}`	`knowledge.update`	`knowledge.update`
`DELETE /knowledge-bases/{id}` (204)	`knowledge.delete`	`knowledge.delete`
`POST /knowledge-bases/{id}/archive`	`knowledge.archive`	`knowledge.archive`
`GET /knowledge-bases/{id}/documents`	`knowledge.documents`	`knowledge.list_documents`
`POST /knowledge-bases/{id}/documents` (201, multipart)	`knowledge.uploadDocument`	`knowledge.upload_document`
`GET /knowledge-bases/{id}/documents/{doc}`	`knowledge.getDocument`	`knowledge.get_document`
`GET /knowledge-bases/{id}/documents/{doc}/status`	`knowledge.documentStatus`	`knowledge.document_status`
`DELETE /knowledge-bases/{id}/documents/{doc}` (204)	`knowledge.deleteDocument`	`knowledge.delete_document`
`POST /knowledge-bases/{id}/documents/{doc}/retry`	`knowledge.retryDocument`	`knowledge.retry_document`
`GET /knowledge-bases/{id}/documents/{doc}/chunks`	`knowledge.documentChunks`	`knowledge.document_chunks`
`POST /knowledge-bases/{id}/search`	`knowledge.search`	`knowledge.search`
`POST /knowledge-bases/search`	`knowledge.searchMultiple`	`knowledge.multi_search`
`POST /knowledge-bases/{id}/hybrid-search`	`knowledge.hybridSearch`	`knowledge.hybrid_search`
`POST /knowledge-bases/{id}/retrieve-context`	`knowledge.retrieveContext`	`knowledge.retrieve_context`
`GET /knowledge-bases/info/supported-file-types`	`knowledge.supportedFileTypes`	`knowledge.supported_file_types`

Full 1:1 coverage (19 methods each). Note the two name differences beyond casing: documents / list_documents and searchMultiple / multi_search. Managed (modulexdb) search and ingest are billed in credits — see Managed knowledge.

organizations

Route	modulex-js	modulex-python
`POST /organizations`	`organizations.create`	`organizations.create`
`GET /organizations/llms`	`organizations.llms`	`organizations.llms`
`POST /organizations/invite`	`organizations.invite`	`organizations.invite`
`POST /organizations/invite/preview`	`organizations.invitePreview`	`organizations.preview_invite`
`POST /organizations/invitations/{id}/cancel`	`organizations.cancelInvitation`	`organizations.cancel_invitation`
`POST /organizations/invitations/{id}/reinvite`	`organizations.reinvite`	`organizations.reinvite`
`PUT /organizations/{orgId}/users/{userId}/role`	`organizations.updateRole`	`organizations.update_user_role`
`DELETE /organizations/{orgId}/users/{userId}`	`organizations.removeUser`	`organizations.remove_user`
`GET /organizations/settings`	`organizations.getSettings`	`organizations.get_settings`
`PUT /organizations/settings/llm-model-visibility`	`organizations.setModelVisibility`	`organizations.set_llm_model_visibility`
`PUT /organizations/settings/composer-llm`	`organizations.setComposerLlm`	`organizations.set_composer_llm`

The member role is retired. Invite and role-update methods accept only 'admin'; passing 'member' returns 422. The live organization roles are owner and admin only, and composer / assistant / knowledge routes require owner or admin (organization_admin_required). The Python assistant docstring’s “org member access” wording understates this — a former member is treated as having no access. See Roles and permissions.

api-keys

Route	modulex-js	modulex-python
`POST /api-keys` (201)	`apiKeys.create`	`api_keys.create`
`GET /api-keys`	`apiKeys.list`	`api_keys.list`
`GET /api-keys/{id}`	`apiKeys.get`	`api_keys.get`
`DELETE /api-keys/{id}`	`apiKeys.revoke`	`api_keys.revoke`

organization_id is sent in the request body here, not via the X-Organization-ID header. apiKeys.revoke is unusual: the backend DELETE returns a JSON body with 200 (not 204), so both SDKs parse a result — unlike credentials/knowledge delete, which return 204.

dashboard

Route	modulex-js	modulex-python
`GET /dashboard/logs`	`dashboard.logs`	`dashboard.logs`
`GET /dashboard/analytics/overview`	`dashboard.analyticsOverview`	`dashboard.analytics_overview`
`GET /dashboard/analytics/tools`	`dashboard.analyticsTools`	`dashboard.analytics_tools`
`GET /dashboard/analytics/llm-usage`	`dashboard.analyticsLlmUsage`	`dashboard.analytics_llm_usage`
`GET /dashboard/users`	`dashboard.users`	`dashboard.users`

All five dashboard routes return HTTP 200 with a success:false envelope on failure, bypassing the SDK error-mapping path. JavaScript callers must branch on the success field rather than rely on a thrown error; the Python SDK handles the nested-data envelope via its page unwrapper. See Errors and status codes.

notifications

Route	modulex-js	modulex-python
`GET /notifications`	`notifications.list`	`notifications.list`
`POST /notifications/organization`	`notifications.create`	`notifications.create`
`POST /notifications/system`	—	—

notifications.create maps to /notifications/organization, not /notifications. GET /notifications returns a null organization_id without a valid org context. POST /notifications/system is commented out backend-side, so neither SDK has a method — not a gap.

system

Route	modulex-js	modulex-python
`GET /system/health`	—	`system.health`
`GET /system/timezones`	`system.timezones`	`system.timezones`
`GET /system/timezones/search`	`system.searchTimezones`	`system.search_timezones`

GET /system/health is a JavaScript gap: client.system is documented as “health and utility” but exposes no health() method. Python has system.health. timezones/search requires q to be at least 2 characters (else 422).

subscriptions (Python-only)

Route	modulex-js	modulex-python
`GET /subscriptions/organization-plans`	—	`subscriptions.organization_plans`
`GET /subscriptions/organization-billing`	—	`subscriptions.organization_billing`
`POST /subscriptions/checkout-link`	—	`subscriptions.checkout_link`
`POST /subscriptions/customer-portal`	—	`subscriptions.customer_portal`
`GET /subscriptions/wallet`	—	—
`PATCH /subscriptions/wallet/extra-usage`	—	—
`POST /subscriptions/wallet/topup`	—	—
`POST /subscriptions/transition`	—	—
`POST /subscriptions/transition/cancel`	—	—

This is the largest parity gap. The four subscriptions.* methods exist only in Python; the wallet and transition routes have no method in either SDK. To call any of these from JavaScript — or to call the wallet/transition routes from either SDK — issue the REST request directly:

curl https://api.modulex.dev/subscriptions/organization-plans \
  -H "Authorization: Bearer mx_live_xxx" \
  -H "X-Organization-ID: org_xxx"

# Python: first-class method
plans = await client.subscriptions.organization_plans()

// JavaScript: no subscriptions resource — call the route directly
const res = await fetch("https://api.modulex.dev/subscriptions/organization-plans", {
  headers: {
    Authorization: "Bearer mx_live_xxx",
    "X-Organization-ID": "org_xxx",
  },
});
const plans = await res.json();

See Subscriptions and Stripe and Wallet and top-ups for what these routes do.

Method-name divergences

For the same backend route, these names differ by more than casing. Everywhere else, the rule is JS camelCase ↔ Python snake_case of the same verb (setDefault ↔ set_default, getState ↔ get_state, retryRun ↔ retry_run).

Backend route	modulex-js	modulex-python
`PATCH /composer/chat/{id}/focus`	`composer.focus`	`composer.set_focus`
`POST /organizations/invite/preview`	`organizations.invitePreview`	`organizations.preview_invite`
`PUT /organizations/{org}/users/{user}/role`	`organizations.updateRole`	`organizations.update_user_role`
`GET /integrations/tools/{name}`	`integrations.tool`	`integrations.tool_detail`
`GET /integrations/llm-providers/{name}`	`integrations.llmProvider`	`integrations.llm_provider_detail`
`GET /integrations/knowledge-providers/{name}`	`integrations.knowledgeProvider`	`integrations.knowledge_provider_detail`
`GET /knowledge-bases/{id}/documents`	`knowledge.documents`	`knowledge.list_documents`
`POST /knowledge-bases/search`	`knowledge.searchMultiple`	`knowledge.multi_search`
`POST /credentials/mcp-server`	`credentials.mcpServer`	`credentials.create_mcp_server`
`POST /credentials/{id}/refresh-discovery`	`credentials.refreshDiscovery`	`credentials.refresh_mcp_discovery`
`GET /workflow-runs` and `/{run_pk}`	`workflowRuns.list` / `workflowRuns.get`	`executions.list_runs` / `executions.get_run`

Pagination and auto-paginators

Pagination style is per-resource, and the SDKs add convenience auto-paginators over the same routes — these are not separate endpoints. See Pagination.

Resource	Style	JS auto-paginator	Python auto-paginator
workflows	page	`workflows.listAll`	`workflows.list_all`
workflow-runs	offset / `has_more`	—	`executions.iter_runs`
composer / assistant lists	cursor	—	—
chats.messages	offset / limit	—	—
chats.list	none (folder-grouped)	—	—

The JavaScript SDK auto-paginates workflows only. Python adds executions.iter_runs (offset over GET /workflow-runs) and workflows.list_all (page). Both auto-paginators are async iterators that call the underlying list route repeatedly.

Coverage gaps (explicit)

A complete accounting of where coverage is not 1:1.

Routes with no method in either SDK

These are intentionally unexposed (webhook receivers, internal intake, ops diagnostics, super-admin console, and the wallet/transition billing routes).

Show Whole routers absent from both SDKs

Router (prefix)	What it is	In any SDK?
`stripe_webhooks` (`/stripe`)	Stripe-to-server webhook receiver	No — not a client call
`requests_api` (`/requests`, deprecated alias `/support`)	support and integration-request intake	No SDK resource
`health_api` (`/system/health` diagnostics, e.g. `/system/health/oauth`)	API-key-gated OAuth diagnostic	No — Python has the types but no method calls it
`admin_api` (`/admin`)	super-admin console (overview, credit logs, org management)	No SDK resource

Show Individual routes absent from both SDKs

Route	Reason
`POST /schedules/admin/trigger-tick`	hidden admin tick (`include_in_schema=False`)
`GET /credentials/oauth2/callback`	browser redirect target (by design)
`POST /notifications/system`	commented out backend-side
`GET /subscriptions/wallet`	not surfaced by either SDK
`PATCH /subscriptions/wallet/extra-usage`	not surfaced by either SDK
`POST /subscriptions/wallet/topup`	not surfaced by either SDK
`POST /subscriptions/transition`	not surfaced by either SDK
`POST /subscriptions/transition/cancel`	not surfaced by either SDK
`GET /system/health/oauth`	OAuth diagnostic; types-only on Python

Routes present in one SDK only

Route	Missing from	Present in
`GET /system/health`	JavaScript	Python (`system.health`)
`GET /subscriptions/organization-plans`	JavaScript	Python (`subscriptions.organization_plans`)
`GET /subscriptions/organization-billing`	JavaScript	Python (`subscriptions.organization_billing`)
`POST /subscriptions/checkout-link`	JavaScript	Python (`subscriptions.checkout_link`)
`POST /subscriptions/customer-portal`	JavaScript	Python (`subscriptions.customer_portal`)

Backend-route coverage

None. Every documented method in both SDKs maps to a real backend route. The only “method without a 1:1 typed route” cases are convenience auto-paginators (workflows.listAll / list_all, executions.iter_runs) that re-call an existing list route, and the bulk-keys SSE factory that maps to POST /credentials/bulk-modulex-keys/stream. If a future method ships without a route, it must be flagged here.

Behavior divergences for the same route

These are not coverage gaps, but they change how you write code against the same endpoint in each SDK.

Behavior	modulex-js	modulex-python
Response shape	raw JSON, snake_case, no model	typed Pydantic models, snake_case
`resume.llm` (composer)	optional in type (backend `400` without)	optional in type (backend `400` without)
`resume.llm` (assistant)	required in type	required in type
`credentials.list` return	discriminated grouped/flat union	raw `Any`
`apiKeys.revoke` response	parses JSON body (`200`)	parses JSON body (`200`)
Dashboard failures	`200` + `success:false` (no throw)	`200` + `success:false` (handled by page unwrapper)
`402` error class	none — falls through to base `ModulexError`	`PaymentRequiredError` (+ `CreditExhaustedError` / `WalletError` / `QuotaExceededError`)
`410` error class	none — base `ModulexError`	none — base `ModulexError`
SSE retry/timeout	`streamSSE` bypasses the `maxRetries` + `timeout` path	SSE uses no read timeout (`read=None`)
`listen` vs `stream` yield (JS)	`listen` yields unwrapped `frame.data`; `chats.stream` yields the wrapped `SSEEvent`	—

The 402 / 410 typing difference matters for retry logic — the Python SDK gives you billing-specific exception classes to branch on, while JavaScript surfaces both as the base error. See SDK errors and retries and Errors and status codes.

Open questions

These items are unresolved against source and are documented rather than guessed:

Show Unverified or unresolved parity details

schedules.retryRun / retry_run response keys. The backend types the response as a bare dict. Both SDKs type it as {message, original_run_id}, but the exact dict contents are unconfirmed against source.
organizations method-count tally (12 JS vs 11 Python). Both SDKs cover the same 11 organization routes; the JavaScript note tallies 12. This appears to be a tally artifact, not an extra route. Treat the resource as full parity by route.
Backend headline endpoint counts. The JavaScript README’s “130 endpoints” and Python’s “~120 methods” figures were not re-derived from a route sum. The matrix on this page is the authoritative coverage list regardless of either headline figure.
admin_api full route set. The /admin/* routes were sampled, not exhaustively enumerated. Confirm the complete admin route list before claiming the router is fully “no SDK” covered.

SDKs overview

Install once, use across every operation.

JavaScript SDK

Install, configure, and the raw-response behavior.

Python SDK

Async client, env fallback, and the subscriptions resource.

Errors and retries

Error classes, retry policy, and the idempotency no-op.

Overview

SDKs

Endpoints

Realtime

MCP server

SDK to API parity matrix

How to read this page

The three structural divergences

Header divergences (the small ones)

Resource-group coverage

The route-to-method matrix

auth

workflows (CRUD and builder)

executions (run, state, resume, cancel, listen)

workflow-runs (durable history)

deployments

schedules

composer

assistant

chats

credentials

integrations

knowledge-bases

organizations

api-keys

dashboard

notifications

system

subscriptions (Python-only)

Method-name divergences

Coverage gaps (explicit)

Routes with no method in either SDK

Routes present in one SDK only

Backend-route coverage

Behavior divergences for the same route

Open questions

SDKs overview

JavaScript SDK

Python SDK

Errors and retries

​How to read this page

​The three structural divergences

​Header divergences (the small ones)

​Resource-group coverage

​The route-to-method matrix

​auth

​workflows (CRUD and builder)

​executions (run, state, resume, cancel, listen)

​workflow-runs (durable history)

​deployments

​schedules

​composer

​assistant

​chats

​credentials

​integrations

​knowledge-bases

​organizations

​api-keys

​dashboard

​notifications

​system

​subscriptions (Python-only)

​Method-name divergences

​Pagination and auto-paginators

​Coverage gaps (explicit)

​Routes with no method in either SDK

​Routes present in one SDK only

​Backend-route coverage

​Behavior divergences for the same route

​Open questions

​Related pages

SDKs overview

JavaScript SDK

Python SDK

Errors and retries

How to read this page

The three structural divergences

Header divergences (the small ones)

Resource-group coverage

The route-to-method matrix

auth

workflows (CRUD and builder)

executions (run, state, resume, cancel, listen)

workflow-runs (durable history)

deployments

schedules

composer

assistant

chats

credentials

integrations

knowledge-bases

organizations

api-keys

dashboard

notifications

system

subscriptions (Python-only)

Method-name divergences

Pagination and auto-paginators

Coverage gaps (explicit)

Routes with no method in either SDK

Routes present in one SDK only

Backend-route coverage

Behavior divergences for the same route

Open questions

Related pages