Mailery client

The public Apache-2.0 CLI, MCP server and SDK for mailery.co. This source workspace builds the single public package @hasna/mailery.

bun add @hasna/mailery

Use the mailery executable or import MaileryClient from @hasna/mailery/sdk. The client calls the hosted HTTPS API; it does not run a local mail server or access a database/provider account.

• CLI and MCP usage

• SDK usage

• Public OpenAPI contract

Development

Use Bun 1.3.14 and Node 22.14 or newer. Install the frozen workspace, then run all client checks:

bun install --frozen-lockfile
bun run publish:check

The checks cover source boundaries, types, CLI/MCP/SDK behavior, public API contract, real Node imports, clean packed-package installs and the positive tarball allowlist. The internal SDK workspace is bundled into @hasna/mailery and remains private to npm.

Related MCP server: EmpirioLabs AI MCP server

Release

Only .github/workflows/publish-npm.yml publishes. It runs on GitHub-hosted runners in the protected npm-publish environment and uses npm provenance. Configure the npm trusted publisher for hasna/mailery, workflow publish-npm.yml, environment npm-publish. Protect the main branch and require release review before enabling publication. Before dispatching the workflow into npm-publish, the publisher must verify a GO recorded in project-linked Hasna Files from a distinct agent's review of the exact candidate in a fresh context in the publisher's native harness. The GO must bind the commit, tree, package, version, registry, access, distribution tag, workflow revision, and environment. The workflow refuses any other repository or branch.

For an initial package publication that needs bootstrap authentication, the optional protected environment secret HASNA_NPM_BOOTSTRAP_TOKEN supplies the approved npm organization credential. Remove it after the trusted publisher is established. Never commit credentials or .npmrc authentication settings.

A successful build or packed-file test does not establish publication. Verify the exact registry version's provenance and perform clean executable and SDK installs after publishing.

0.2.0

Checkout retries can retain a caller-owned purchase key through SDK createCheckout({ idempotencyKey }) and CLI subscribe --idempotency-key. Keep that key after a timeout or uncertain outcome; a new key starts a deliberate new purchase. Use subscribe --resume to check entitlement without creating another Checkout session. New paid purchases require a declared billing or residence country and the exact policy version returned by billing countries / getCheckoutCountryPolicy(). Present those restrictions before collecting the declaration. Preserve all original declaration fields on retries. Omit them only to replay an exact pre-country purchase with its original key. Free signup requires explicit acceptance of the current Terms version, and remains available without a country declaration.

Show the exact Terms link and version to the person. Run mailery terms --accept <exact-version> or MCP accept_terms only after an explicit yes from the person or an agent they authorized. Never select a default/latest version. The server refuses a version that is not currently published. CLI signup JSON includes data.terms on success and error.terms on any failure after successful discovery. Object-valued error details also retain details.terms; unrelated detail fields and non-object details are preserved. MCP signup includes terms after discovery. A version-race error (terms_version_changed, HTTP 409) supplies newer authoritative Terms: both clients prefer that server version and resolve its URL against the configured API base, including the copy in server error details. Other later errors retain the successful preflight URL and exact version. A failed Terms preflight adds no discovery fields. Neither client fetches Terms again after signup. mailery terms --json and MCP get_terms expose url and version directly in their discovery result. SDK method response shapes are unchanged.