Frequently asked questions

ZidiMail is a transactional email API and dashboard: verify sending domains, create API keys, send mail from your backend, track delivery, and optionally receive webhooks. Technical details live in the documentation.

Yes. You add a domain you control, publish the DNS records we show (SPF, DKIM, and related checks), then verify from the Domains page. Until the domain is verified, the API will not accept sends from that domain.

New or restricted organizations may be limited to sending only to your account owner email. That lets you test integration safely. To send to real users, complete onboarding and move out of sandbox per the message returned by the API.

The From address must use a domain that shows as verified in your dashboard. Double-check DNS at your DNS host, wait for propagation, then use “Verify” on the domain. SPF and DKIM must pass for verification.

Keys look like zm_live_…. Creating and revoking keys uses your dashboard session (JWT). Sending email requires an API key — store it only on servers, never in a browser bundle or public repo.

The Authorization header must be exactly Bearer followed by your full key. Partial keys, revoked keys, or typos return 401. If you lost the secret, revoke the old key and create a new one.

Limits include per-IP caps on sensitive routes, free-plan burst (e.g. sends per second), daily and monthly quotas per plan, and warm-up rules for new accounts. When exceeded, the API returns 429 with a message. See the rate limits table in /docs.

Addresses that hard-bounced or filed spam complaints are blocked from future sends to protect your reputation. If all recipients in a request are suppressed, you get 422. Remove bad addresses from your lists and fix content/list hygiene.

You register an HTTPS URL and choose events (sent, delivered, bounced, complained, opened, clicked). We POST JSON and sign the body with HMAC-SHA256; verify using the secret shown once at creation. See the Webhooks section in docs.

You should not expose API keys in the frontend. The API CORS policy is tied to your dashboard origin for cookie-based dashboard calls; server-to-server integration should run from your backend.

Plans (Free, Pro, Scale) set monthly and daily sending limits. Upgrades run through the dashboard billing flow (PayPal subscriptions). Overage and pricing details are summarized in the documentation.

After policy or JWT changes, a fresh login ensures your session cookie carries the latest claims. Hard-refresh the dashboard if the UI looks cached. For API behavior, confirm your deployment is on the latest backend revision.

Use the support channel or email referenced in your onboarding materials. For integration questions, start with /docs and the dashboard in-app pages (Domains, API Keys, Webhooks). For terms and privacy, see Legal.

All legal documents are listed on the Legal page, including Terms of Service, Privacy Policy, Cookie Policy, Acceptable Use, DPA, and Subprocessors.