Email account provisioning, built into your workflow.

A creation request identifies the provider and quantity. MailMaker returns a stable task ID with the estimated credit cost and current status. Your application can persist that ID instead of trying to mirror provider-specific execution details.

Statuses move through a small lifecycle: queued, processing, completed, partial, or failed. Final responses separate requested, successful, and failed counts so your application can reconcile results and credits directly.

• Idempotency keys for safe retries
• Explicit provider and quantity validation
• Task-level progress and result retrieval
• Clear successful and failed account counts

The API is designed for asynchronous task orchestration: validate a request, create one durable task, observe explicit state through bounded polling, and retrieve the authoritative final result. It is not a synchronous endpoint that should remain open until every account completes.

Write the intended use, owner, expected quantity, provider choice, result destination, and retention period before execution. A visible scope prevents convenience from turning into ungoverned volume.

• API-key scope
• Idempotency ownership
• State mapping
• Polling interval and deadline
• Retry and manual recovery policy

An internal portal accepts an approved account request, creates an idempotency key, stores it with the internal job, submits the MailMaker task, and returns immediately. A worker retrieves the task on a backoff schedule until it reaches a terminal state, then reconciles the result.

The pattern is consistent: validate with the real configuration, retain the task ID, compare requested and completed counts, confirm actual credit usage, and obtain acceptance from the result owner before repeating or expanding the work.

Monitor request validation failures, idempotent replays, polling frequency, tasks exceeding maximum age, partial completion, reconciliation mismatches, and manual-review queue time.

Attach measurements to the source task and internal request. Aggregate reporting should be derived from those records so a headline total cannot hide provider differences, partial results, duplicate attempts, or unresolved credential handling.

• Requested versus successful
• Estimated versus actual credits
• Processing and reconciliation duration
• Replacement task volume
• Security and retention exceptions

Confirm authorization, scope, provider, quantity, budget, owner, execution method, status handling, result destination, and deletion plan. If the workflow uses an API, also verify key scope, idempotency, bounded polling, bounded retries, and credential-safe logging.

After completion, record final counts and credit use, document the handoff, close exceptions, and update the checklist with what changed. A repeatable workflow should become more predictable after every reconciled task.

• Purpose and owner approved
• Cost and limits reviewed
• Failure handling tested
• Secure result destination ready
• Reconciliation responsibility assigned
• Retention review scheduled