Skip to main content

sendmux-sdk

PyPI version Python versions PyPI downloads Licence

Optional umbrella package for the Sendmux Python SDK.

Documentation

Requirements

  • Python 3.10 or newer.
  • A send-capable smx_mbx_* key or owner-approved Sending-resource smx_agent_* token for Sending clients.
  • A mailbox-scoped smx_mbx_* key or scoped smx_agent_* token for Mailbox clients.
  • A root smx_root_* key for Management clients.

For OAuth, use a REST access token with the scopes and mailbox access required by the operation. See OAuth for REST APIs.

Installation

pip install sendmux-sdk

Connection checks

Check a Management credential without creating resources:

import os

from sendmux_sdk import management

with management.create_management_client(
    api_key=os.environ["SENDMUX_MANAGEMENT_API_KEY"]
) as client:
    connection = management.ConnectionApi(client).management_get_connection()
    print(connection.data.label, connection.data.team.id)

Use data.label for the connection name and data.team.id for its stable team identifier. Each API surface has its own connection operation:

Surface API class Method
Management management.ConnectionApi management_get_connection()
Mailbox mailbox.MailboxAPIApi mailbox_get_connection()
Sending sending.MetaApi sending_get_connection()

Create each client with the credential for that surface.

OAuth access tokens

Pass either api_key or access_token. access_token accepts a bare token string or a synchronous callable; the callable is evaluated for each authenticated request. Your application owns token storage, expiry checks and refresh coordination.

import os

from sendmux_sdk import management

client = management.create_management_client(
    access_token=lambda: os.environ["SENDMUX_ACCESS_TOKEN"]
)

Usage

import os

from sendmux_sdk import sending

client = sending.create_sending_client(api_key=os.environ["SENDMUX_SENDING_API_KEY"])
api = sending.EmailsApi(client)

response = api.sending_send_email(
    sending.EmailSendRequest(
        var_from=sending.Address(email="sender@example.com"),
        to=sending.Address(email="recipient@example.com"),
        subject="Hello from Sendmux",
        html_body="<p>Hello.</p>",
        text_body="Hello.",
    ),
    idempotency_key="email_123",
)

print(response.data.message_id)

The umbrella package lazy-loads:

  • core from sendmux_core
  • sending from sendmux_sending
  • mailbox from sendmux_mailbox
  • management from sendmux_management

Use the per-surface packages directly when an integration only needs one API surface.

Version 3.0.0 migration

SDK 3 adopts Management 2 and Sending 1.6. The management module's provider-list responses contain ProviderListItem objects instead of ProviderItem objects. Detail responses retain ProviderItem and require the variables map; list items omit that map.

To migrate from SDK 2:

  1. Update your requirements to sendmux-sdk>=3.0.0,<4.0.0 and regenerate your lockfile. If you pin components directly, use sendmux-management>=2.0.0,<3.0.0 and sendmux-sending>=1.6.0,<2.0.0; the Core >=1.3.1,<2.0.0 and Mailbox >=2.0.0,<3.0.0 ranges are unchanged.
  2. Change provider-list annotations and type checks from management.ProviderItem to management.ProviderListItem. Keep management.ProviderItem for detail responses, and include variables in detail fixtures ({} when none are set).
  3. Run python -m pip check and your provider-list, provider-detail, and sending tests. Confirm list items use ProviderListItem, detail fixtures retain their variables, and delivery-group requests serialize the selected group.

To roll back, restore the previous SDK and component requirements, lockfile, and affected call sites together.

Version 2.0.0 migration

The umbrella's mailbox module adopts the thread-specific list response: thread-message results require meta.thread_id and expose optional typed meta.sync_state, while ordinary message-list results remain thread-independent. Other Mailbox list families expose typed state metadata where applicable.

Update sendmux-sdk, sendmux-mailbox, the lockfile, and affected annotations or fixtures together. To roll back, restore the previous package requirements, lockfile, and call sites together.

Support

Open an issue in Sendmux/sendmux-sdk with the package name, version, and request ID from any API error.

Licence

MIT. See the licence file.

Metadata

Release files for sendmux-sdk 3.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for sendmux-sdk 3.0.0
File Size Uploaded
sendmux_sdk-3.0.0.tar.gz 5.3 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for sendmux-sdk 3.0.0
File Interpreter ABI Platform
sendmux_sdk-3.0.0-py3-none-any.whl Python 3 none any Details

Total release size: 9.6 kB

Release files / sendmux_sdk-3.0.0.tar.gz

Download URL sendmux_sdk-3.0.0.tar.gz
Size 5.3 kB
Tags Source
SHA-256 checksum
How to use checksums
9a98bc6dc938ca8e1d75f2dbbaf9d0a186a3c121731778d7b04a6f355f0a3e49
BLAKE2b-256 checksum
How to use checksums
476a97515cd10e83eca23c91910a6adfb23986060585f69458a5031794fd7921
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.

Transparency log

Release files / sendmux_sdk-3.0.0-py3-none-any.whl

Download URL sendmux_sdk-3.0.0-py3-none-any.whl
Size 4.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
b8b5685483e9212183ac43ac3aedd7dc0ca60f5cb096db0a942720474c18178b
BLAKE2b-256 checksum
How to use checksums
5a6eb389f1a777fbb235a777bc5e35ab2505354b8030daac82f3d8d2ce469fbf
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.

Transparency log

Release history Release notifications | RSS feed

3.0.1

2 release files

This release

3.0.0 This release

2 release files

2.0.0

2 release files

1.2.0

2 release files

1.1.1

2 release files

1.1.0

2 release files

1.0.4

2 release files

1.0.3

2 release files

1.0.2

2 release files

1.0.1

2 release files

1.0.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page