Build with ZMAIL. 🚀

ZMAIL is a controlled email-sending API built for developers, bots, and automation workflows. You send one authenticated HTTPS request and ZMAIL handles delivery through a monitored SMTP pipeline.

It's designed for notifications, OTPs, form alerts, and status pings — not bulk marketing. Think of it as a lightweight, trustworthy relay between your code and someone's inbox.

Developer access is gated. Enter your Developer Secret Key above to unlock the docs. If you don't have one, request it via the Contact section.

Keys are issued manually to keep shared capacity stable. Expect a short wait while your request is reviewed — this isn't a signup form, it's a handshake. 🤝

Two different keys, two different jobs:

• Developer Secret Key — unlocks this documentation portal. Never send it in API requests.
• Developer API Key — used in the Authorization: Bearer … header of every send request.

Never mix them up. Leaking either is bad; leaking the API key is worse — it can send mail as you.

Each authorized key has 95 successful operations per rolling 24-hour window on the free tier. Premium tiers raise the cap.

The counter is server-side and resets on a rolling basis — not at midnight. Exceeding it returns HTTP 429 Too Many Requests with a Retry-After header.

The standard tier is free within its daily allowance — 95 ops per 24 hours, indefinitely.

Premium access (higher limits, priority delivery, dedicated support) is available at the fixed price published by the developer. Request it via Contact. No hidden auto-billing — everything is manual. 💸

Yes. Attachments go in the JSON payload as base64, or as inline images using cid: references — the latter renders directly inside the email without a "display images" prompt.

Keep total payload under ~3 MB. Base64 inflates size by roughly 33%, and API caps request bodies at 4.5 MB.

Most common reasons:

• Typo or extra whitespace when pasting the key.
• Key expired or was revoked.
• Using the Secret Key where the API Key belongs (or vice versa).
• Daily / hourly rate limit hit.
• You're sending from a blocked IP or region.

If none of these apply, contact the developer with the exact error message.

No. ZMAIL is explicitly not a bulk-marketing tool. Sending unsolicited promotional email will get your key revoked without warning.

For campaigns, use a service built for it: Mailchimp, Brevo, Resend Broadcasts, SendGrid, etc. They have compliance tooling, unsubscribe management, and delivery IPs that ZMAIL doesn't.

Anything that can make an HTTPS request. The docs cover cURL, JavaScript (fetch / Node), and Python (requests).

No official SDK — and honestly, you don't need one. The endpoint is a single clean POST with a JSON body. If your language can send an HTTP request, it can send ZMAIL.

Requests travel over HTTPS only. Your API key is sent in the Authorization header — never in URLs, which would leak it into logs and referrers.

ZMAIL does not store email bodies beyond delivery logs. Never send passwords, full card numbers, or sensitive personal data through any email API.

You'll receive HTTP 429 with a Retry-After header telling you when to try again. Your quota resets on a rolling 24-hour window.

Repeated limit abuse — like hammering the endpoint in a retry loop — can lead to key suspension. Back off when you see a 429. ⏸️

Contact the developer via the section below. Keys are rotated manually — self-serve rotation is on the roadmap but not live yet.

If your key is leaked, tell the developer immediately. Faster rotation beats damage control every time.

Use the Contact section — WhatsApp is fastest. Include:

• Your request ID (from the error response).
• The timestamp (in UTC if possible).
• The exact error message and HTTP status code.
• A screenshot if it helps.

Vague reports slow everything down. Specific ones get fixed. 🧰

Short answer: not by default. Emails go out from the ZMAIL domain with SPF / DKIM / DMARC aligned — that's what keeps them out of spam.

Custom "From" addresses require verifying your own domain, which is a premium feature. Contact the developer if you need it.

Technically yes — the to field accepts a comma-separated list or an array. But each recipient in a single request counts as one operation.

Sending to 50 people in one call burns 50 ops off your daily allowance. If you need a genuine mailing list, use a bulk provider.

Yes. ZMAIL delivers through standard SMTP with proper SPF, DKIM, and DMARC records, so mail lands in the inbox of every major provider.

That said, no email API can guarantee inbox placement 100%. Content, sender reputation, and recipient behavior all matter. Follow our usage rules and delivery stays clean.

Not if used correctly. ZMAIL is SPF/DKIM/DMARC aligned and sends from a warmed, monitored domain.

Spam placement is usually caused by:

• Spammy subject lines (ALL CAPS, "FREE!!!", excessive emojis).
• Sending to people who didn't opt in.
• Embedded tracking pixels or shortened URLs.
• High bounce rates from invalid addresses.

Keep it clean and delivery is clean. ✨

No built-in scheduling — ZMAIL sends immediately when you hit the endpoint.

For scheduled sends, use a cron job, GitHub Actions schedule, or a Node setTimeout. Anything that can call your endpoint at a specific time works.

Yes. The body field accepts HTML and ZMAIL sends with Content-Type: text/html. You can use headings, images, links, styled tables — anything that renders in a browser inbox.

Tip: keep HTML under ~100 KB. Gmail clips messages larger than that with a "[Message clipped]" footer. Resize images, inline critical CSS, and you'll be fine.

It means ZMAIL's server accepted your request, authenticated it, confirmed you had quota available, and handed the email to the mail provider — which then accepted it.

It does not mean the recipient's inbox has the email yet, or that they've opened it. Delivery to the inbox depends on many factors: the recipient's provider, spam filters, their personal settings, and the content of your email.

A "sent successfully" status is the last confirmed milestone on our side.

First, confirm the send was successful — you should have seen a "Sent successfully" message with a message ID. If it was, the email left our server.

From there, check these places in order:

📥 Your inbox.
🏷️ The Promotions or Updates tab if you use Gmail.
🚫 Your Spam or Junk folder.
🔍 Any custom filters or rules you've set up that might have moved it.

Also make sure the recipient address was spelled correctly — a single typo can send the email to the wrong person or nowhere at all.

If you still can't find it after checking all of these, the receiving provider may have silently dropped it. Contact the developer with the message ID for investigation.

No — never. Your API key would be visible in browser DevTools to anyone who opens the page.

Always call ZMAIL from a server: Node backend, Cloudflare Worker, Python script, etc. If you need the browser to trigger an email, route through your own backend first.

Not yet — every successful send counts against your daily quota.

For testing, send to your own address. If you need heavy testing, request a sandbox key from the developer. It won't deliver real mail but lets you exercise the request/response cycle safely.

ZMAIL logs accepted, rejected, and bounced events at the SMTP level. The response to your send request includes a status and, on failure, a reason.

Deep tracking — open rates, click rates, per-message telemetry — is not supported. If you need that, use a marketing platform. ZMAIL is a relay, not an analytics suite. 📊

Total payload limit is 4.5 MB Since base64 encoding adds ~33% overhead, keep raw attachments under ~3 MB.

For larger files, upload to a host (ImgBB, S3, Cloudinary) and put the link in the email body instead.

ZMAIL keeps minimal logs: request ID, recipient domain, status, timestamp, and error reason if any. Email bodies are not stored beyond the delivery attempt.

Logs are kept for a short retention window for troubleshooting and abuse detection, then discarded.

Yes — within the usage rules. Commercial use is fine as long as you're not sending unsolicited bulk mail, spam, phishing, or anything illegal.

If your commercial use requires higher volume, contact the developer about premium access. Trying to run a business on the free tier's 95 ops/day will not end well. 😅

You're responsible for the data you send through ZMAIL. That means:

• Only email people who consented.
• Include an unsubscribe link in commercial mail.
• Honor deletion requests promptly.
• Don't send personal data you don't have a lawful basis to process.

ZMAIL doesn't inspect or sell your content, but compliance is on you, not the relay.

Premium is issued manually and priced as-is. Refunds are handled case-by-case — contact the developer within 7 days of purchase if something's wrong.

Refunds are not given for key revocation due to abuse. Read the rules before upgrading.

No plans to. But if it ever does, premium users get at least 30 days' notice plus a data export. Free users get notice via the docs page and the developer's social channels.

Either way — don't build your entire business on a free relay. Have a fallback provider lined up. 🧯