Docs
Verify signed WillItInbox webhook events, inspect delivery attempts, test endpoints, resend failures, and connect bulk or operational email workflows.
Webhooks are designed for workflows where polling is not ideal. Bulk completion is stable today, while monitoring and alert workflows use the same persistent endpoint, delivery, and resend model.
WillItInbox signs webhook payloads with HMAC SHA-256 so receivers can verify that an event came from the platform and was not modified in transit.
Developer lifecycle
A useful developer stack should preserve evidence as email moves from local development into staging and the real sender path. WillItInbox connects capture, inspection, validation, deliverability reports, and asynchronous automation without treating a sandbox result as proof of production delivery.
Send local or staging messages into an authenticated sandbox project and inspect the rendered message or retained MIME source.
Run the captured message through deliverability analysis, or send the final production-path message to a generated test inbox.
Use CLI exit codes, API responses, reports, and signed webhooks to gate releases or create review tasks.
Choose the right surface
Choose the surface that matches the evidence and timing your workflow needs. Sandbox capture helps during development, APIs and SDKs automate repeatable checks, webhooks report asynchronous outcomes, and real-message tests inspect the final production sender path.
| Surface | Best use | Important limit |
|---|---|---|
| Email sandbox | Capture and inspect development or staging messages safely. | Capture evidence does not reproduce the complete production sender path. |
| REST API | Integrate validation, tests, reports, bulk jobs, and operational evidence. | Clients must handle authentication, quotas, retries, and inconclusive results. |
| Node/Python helpers | Use common workflows with consistent request and error handling. | The API reference remains the source of truth for the complete surface. |
| Signed webhooks | Receive asynchronous completion and delivery events. | Consumers must verify signatures and make processing idempotent. |
| Real-message test | Inspect the message produced by the actual ESP, domain, and sending path. | Technical evidence cannot guarantee universal inbox placement. |
CI policy
A stable CI policy distinguishes hard technical failures from contextual warnings. Persist the report or message identifier so developers can inspect the evidence behind a failed check instead of debugging an unexplained score.
Malformed MIME, broken authentication, missing required headers, capture errors, or a score below an explicitly owned threshold.
Content, reputation, placement, and provider warnings that need campaign or sender context.
Rate limits, temporary provider responses, delayed analysis, or webhook transport failures with bounded backoff.
Integration design
Do not call the API only to display a score. Store the evidence needed for the next decision: suppress, segment, retry, block a release, warn a sender, open an audit task, or notify the domain owner.
Reliability
A production integration should treat validation and deliverability evidence as state. Persist job ids, report tokens, response codes, webhook delivery ids, and final policy decisions. Retry transport failures, but do not blindly retry provider policy blocks.
| API surface | Use it for | Store |
|---|---|---|
| Validation | Signup, import, enrichment, outbound hygiene | status, sub_status, confidence, evidence |
| Bulk | CSV list hygiene and CRM cleanup | job id, summary, download URL, policy decision |
| Reports | Template QA and release checks | token, score, critical findings, PDF/share link |
| Webhooks | Async completion and alerts | event, signature result, delivery status |
Plan model
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.
Newer surfaces
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.
The DMARC docs explain DMARC aggregate/RUF/TLS-RPT separation, mailbox ingestion, source labels, forensic-report handling, and alerts.
Connect Google Postmaster for read-only domain evidence, compliance status, and latest Gmail-side reputation snapshots.
Diagnostic seed tests, schedules, user-authorized SMTP sends, and provider heatmaps are documented as evidence, not a placement guarantee.
DSN bounce ingestion, ARF complaint ingestion, and suppression-aware validation are API-backed workflows for operational hygiene.
Related
Capture development messages, inspect source, and run reusable CI checks.
Review authenticated endpoints, request shapes, errors, and quotas.
Verify HMAC signatures and process asynchronous events safely.
Use Node, Python, and command-line helpers for common workflows.
See how this workflow applies to teams running developer testing, sdks, webhooks, and ci/cd.
Read the supporting guide for practical context around developer testing, sdks, webhooks, and ci/cd.
Review request and response patterns for single validation, bulk verification, suppression, and webhook flows.
Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.
FAQ
No. A sandbox verifies message generation, source, rendering, and configured checks. Run a real-message test through the production sender path before relying on the result.
Verify the signature, store a stable delivery or event identifier, and make processing idempotent before returning success.
No. Fail CI for deterministic critical issues such as broken authentication, missing required headers, or malformed payloads. Warnings should usually create human-review tasks.
Start with email validation API example, then read SDK docs and webhooks.
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.
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.
