SDKs

Official libraries for TypeScript, Python and Go are in progress. This page says what is usable today so you are not waiting on them.

The API needs no library

It is JSON over HTTPS with one header. Every language's standard HTTP client is enough, and the quickstarts show a complete, production-shaped integration in each:

• Node.js
• Next.js
• Python
• Go
• Laravel
• WordPress over SMTP

Those examples include the parts a wrapper would otherwise hide: decoding the error envelope, branching on type, and reusing an idempotency key across retries. Worth understanding once, whatever you end up calling the API from.

Generate a client from the spec

The OpenAPI description is published and current:

https://docs.epostix.com/openapi/v1.yaml

It is the same document our server is built from, so a generated client cannot drift from what the API actually does.

npx openapi-typescript https://docs.epostix.com/openapi/v1.yaml -o epostix.d.ts

oapi-codegen -generate types,client -package epostix \
  https://docs.epostix.com/openapi/v1.yaml > epostix.gen.go

The spec is served with permissive CORS, so it also imports directly into Postman, Insomnia, Scalar and anything else that reads a URL.

Already sending mail another way

If your application already speaks SMTP, point it at smtp.epostix.com and it works unchanged. See SMTP credentials.

SMTP gets you delivery, tracking and the dashboard. Tags, metadata, scheduling, idempotency, templates and the delivery timeline are API-only, so most applications end up using both.

What the libraries will add

Typed requests and responses, the retry and idempotency behaviour from the guides built in, and helpers for verifying webhook signatures. Nothing you cannot do today, but less of it to write.

Our webhook signing is Standard Webhooks compatible, so the existing libraries for that specification already verify our deliveries without waiting for ours.