API Architecture
How OpenSES divides tRPC, public REST APIs, and webhooks.
OpenSES uses each transport where its authentication and compatibility model fits best.
| Surface | Transport | Authentication | Purpose |
|---|---|---|---|
| Dashboard and internal app | tRPC | Better Auth session | Organizations, projects, domains, templates, API keys, logs, and webhook administration |
| Node.js SDK | REST | Project API key | Server-to-server email sending, retrieval, listing, and cancellation |
| Customer webhooks | REST | HMAC signature | Delivery events sent from OpenSES to customer endpoints |
| SES event ingestion | REST | AWS SNS verification | Notifications sent from AWS into OpenSES |
Why the SDK uses REST
The dashboard tRPC router is protected by a browser session. The SDK is designed for backend applications using project-scoped API keys, so reusing that router would couple server integrations to dashboard authentication.
The public /v1/emails REST API is therefore the correct contract for the SDK. It is stable across languages, easy to call from Node.js native fetch, and keeps the package dependency-free.
Supported SDK scope
The SDK exposes methods backed by public API-key endpoints:
emails.sendemails.getemails.listemails.cancelverifyWebhook- Resend-compatible transactional email and webhook verification facade
Domain, template, API key, and webhook administration remain dashboard operations over tRPC until dedicated public API-key procedures are introduced.