Home / Email API
Email service
One send endpoint. Four branded templates. No SDK.
Every email Leadtrak.ai sends — lead notifications, sequence steps, support replies — goes through one mailer with one HTTP entry point. That same endpoint is available to our own applications, so a back-office script can send a branded, attachment-carrying email with a single curl and no mail library.
Honest scope: this is a single shared key for machine-to-machine use, not per-tenant API keys, and it is not yet offered as a public product endpoint. Per-tenant keys are planned.
The endpoint
POST /api/v1/email/send
JSON in, JSON out. Authenticate with Authorization: Bearer <key> or X-Api-Key. Give it from, to, subject and text or html. Send HTML with no text part and a plain-text alternative is derived for you, link targets preserved.
Everything a real message needs
Multiple recipients, cc, bcc, reply_to, from_name, custom X- headers, base64 attachments and inline images by cid. Up to 50 recipients and 20 attachments per request, 10 MB encoded.
| Status | Meaning |
|---|---|
202 | Accepted and handed to the transport |
400 | Body was not valid JSON |
401 | Missing or wrong key |
403 | Sending domain is not on the allow-list |
422 | Validation failed — no body, bad address, bad attachment |
429 | Rate limit exceeded (60 per minute per IP by default) |
502 | Transport rejected the message |
Every one of those codes is asserted by an automated test that makes a real HTTP request against a running server, not a mocked client.
Refusals, by design
You can only send as a domain we configured
Sending domains are an explicit allow-list. A from address outside it is refused with 403 and the key cannot be used to spoof a domain nobody verified.
Attachments are base64 only
A file path is rejected outright. There is no request shape that makes the API read something off our own disk and mail it out.
Headers cannot be injected
CR/LF in a subject, address or header value is neutralised before any header is built, so a crafted subject cannot smuggle in a Bcc:. Proven by a regression test that inspects the built message.
Four templates, branded from the sending domain
You do not pass colours or a logo. The brand is chosen from the from domain, so the same call sends in the right identity for whichever product is sending.
| Template | Use |
|---|---|
welcome | Onboarding, with optional numbered first steps and a call to action |
notification | An event — new lead, alert, enquiry — with a key/value detail table |
report | Periodic digest with three headline figures |
transactional | Password reset, verification code, confirmation |
They are table-based with inline styles, because Outlook and Gmail still ignore <style> blocks, and every value interpolated into them is HTML-escaped.
What is built, and what is not
| Capability | Status |
|---|---|
| Single send endpoint with shared-key auth | Built |
| HTML + plain text, auto text fallback | Built |
| Base64 attachments and inline images | Built |
| Allow-listed sending domains, several at once | Built |
| Per-minute rate limiting | Built |
| Four branded HTML templates | Built |
| Driver abstraction: log, SMTP, Amazon SES | Built |
| Production SES sending switched on | Planned — awaiting domain verification and production access |
| Per-tenant API keys for customers | Planned |
| Bounce and complaint webhooks per domain | Planned |
We list the planned rows rather than quietly implying them. Until production sending is enabled, the service is exercised against the log and capture drivers and by automated tests over real HTTP.
The same mailer that emails you about every new lead
30 days of full Growth access, no card required.