Documentation

Crawlable docs for every WillItInbox workflow.

Start here for public, search-friendly documentation covering deliverability testing, sandbox capture diagnostics, validation, monitoring, DMARC, inbox placement, webhooks, SDKs, and the REST API.

Read API referenceSee examples

70+

deliverability checks

12

validation layers

API

first-class workflow

Start here

What WillItInbox helps you inspect

WillItInbox is built for teams that need to know whether email can reach the inbox before they ship a campaign, transactional flow, or list import.

Deliverability testing

Generate a real test inbox, send a message from your app or ESP, and inspect authentication, DNS, headers, content, and links.

Email validation

Classify addresses as valid, invalid, risky, catch-all, unknown, disposable, role-based, or typo-prone before a send.

Bulk CSV jobs

Upload lists, track progress, download enriched CSV output, and receive signed webhook callbacks when jobs finish.

Domain and DMARC monitoring

Verify sending domains, scan policy drift, ingest aggregate reports, link provider reputation evidence, label sources, and alert on alignment failures.

Inbox placement and incidents

Use seed-backed placement diagnostics and incident reports when a launch, campaign, or transactional flow needs evidence beyond a single score.

Sandbox capture and diagnostics

Create project inboxes, capture local and staging email with generated addresses or SMTP, inspect source, and run CI thresholds.

Developer surface

Docs are organized around workflows, not menus

Each guide explains the job, the evidence WillItInbox collects, the output a team should expect, and the next page to read.

REST API

Authenticated /api/v1 endpoints cover validation, bulk jobs, test inboxes, reports, webhooks, domains, DMARC, provider reputation, and usage.

SDKs

Dependency-light Node and Python clients include validation, reports, sandbox helpers, webhook verification, and wait/check workflows.

CLI

The package-ready CLI can validate addresses, fetch reports, verify webhooks, wait for sandbox messages, and run sandbox threshold checks.

Webhooks

Bulk completion and monitoring workflows can POST signed events to your own endpoint for automation.

Fast paths

Start with the workflow you are recording or shipping

If you are new, start with the guide that matches the evidence you need: message quality, recipient hygiene, domain drift, DMARC sender intelligence, inbox placement, incident diagnosis, or API automation.

  • Use /docs/deliverability-testing when you need to test a real sent message.
  • Use /sandbox when you need to capture development email and inspect source before production.
  • Use /docs/email-validation when you need to clean a list before sending.
  • Use /docs/domain-monitoring and /docs/dmarc-monitoring when you need ongoing sender evidence.
  • Use /docs/inbox-placement when you need seed-backed folder classification.
  • Use /docs/api and /docs/webhooks when you want repeatable automation.

Operating model

Use the docs as a workflow map

WillItInbox docs are written around the jobs teams repeat: testing a real message, validating a recipient, cleaning a CSV, monitoring a domain, reading DMARC reports, receiving webhooks, and using the API. Start with the workflow that matches the risk in front of you, then follow the internal links to the deeper implementation pages.

Run a real-message test

Use /test when the question is whether the exact production email is technically ready.

Validate recipients

Use /validator or /validator/bulk before imports, outbound, newsletters, and reactivation.

Automate checks

Use /docs/api when deliverability QA belongs in CI, release tooling, or an internal workflow.

Evidence

Every page should leave you with an action

The docs should not only define terms. They should explain what evidence WillItInbox collects, what that evidence means, what can be fixed immediately, and what needs ongoing monitoring.

  • Use deliverability testing for real-message authentication, DNS, headers, content, and links.
  • Use email validation for valid, invalid, risky, catch-all, disposable, role, typo, and unknown decisions.
  • Use DMARC monitoring when enforcement depends on knowing every legitimate sender.

Plan model

Pricing uses clear usage quotas plus feature access

WillItInbox plans are easiest to understand when the metered usage stays simple: deliverability tests, email validations, API calls, and bulk CSV rows. Monitoring, webhooks, workspaces, branded reports, placement diagnostics, and trust-layer APIs are shown as feature access until those surfaces need explicit capacity counters.

  • Tests measure generated deliverability reports and placement diagnostics.
  • Validations measure single, batch, API, and bulk recipient checks.
  • API calls cover authenticated automation, including trust-layer ingestion endpoints.
  • Bulk rows cap CSV validation job size and recurring list-hygiene volume.

Newer surfaces

Feature pages carry the detail pricing should not

The pricing page should stay scannable. The docs and feature pages should explain what the newer surfaces do, what evidence they produce, and where they fit in a sender's workflow.

DMARC intelligence

The DMARC docs explain DMARC aggregate/RUF/TLS-RPT separation, mailbox ingestion, source labels, forensic-report handling, and alerts.

Provider reputation

Connect Google Postmaster for read-only domain evidence, compliance status, and latest Gmail-side reputation snapshots.

Inbox placement diagnostics

Diagnostic seed tests, schedules, user-authorized SMTP sends, and provider heatmaps are documented as evidence, not a placement guarantee.

Trust-layer APIs

DSN bounce ingestion, ARF complaint ingestion, and suppression-aware validation are API-backed workflows for operational hygiene.

Related

API reference

/docs/api

DMARC monitoring

/docs/dmarc-monitoring

Inbox placement

/docs/inbox-placement

Sample report

See how findings become fixes.

Email validation API

See a practical API policy.

SaaS solution

Map docs to product email reliability.

FAQ

Where should a new team start?

Start with deliverability testing, email validation, and the API reference. Those three pages cover the message, the recipient, and automation.

Do the docs promise inbox placement?

No. WillItInbox documents diagnostic evidence and risk signals. Placement still depends on reputation, engagement, recipient history, and provider behavior.

Does every newer feature have its own public rate limit?

No. WillItInbox exposes four clear usage quotas today: tests, validations, API calls, and bulk rows. Other workflows are handled as feature access or beta access unless a concrete capacity limit is added later.

Why keep placement and trust-layer language careful?

Placement tests provide diagnostic seed evidence, and trust-layer APIs provide operational ingestion and suppression evidence. Neither should be described as a guarantee of inbox placement or compliance certification.