Log inStart creating →
DEVELOPER QA WORKFLOW

Automated test account provisioning without an endless script.

Turn an approved test requirement into one durable MailMaker task, observe it through explicit states, and return reconciled results to the test system.

Create accounts →See how it works
✓ Failed items use zero credits  ·  No subscription
CREATE TASK
ProviderAPI-selected
QuantityValidated request
Estimated totalPreflight estimate
Failed? Credits returned.
THE SHORT VERSION

Validate, submit once, save the task ID, poll deliberately, stop at a terminal state, and keep credential output outside ordinary logs.

Creation safetyIdempotent

One logical job keeps one durable request key

Status model5 states

Queued, processing, completed, partial, failed

Failure controlBounded

Retries, polling, budgets, and manual review

100%credit-back guarantee

Successful accounts consume credits. Failed accounts do not. Any credits reserved for a failed item return to your MailMaker balance automatically.

Read the guarantee →
01 · REQUEST CONTRACT

Accept an approved test job, not an unbounded quantity prompt.

The calling system should provide a supported provider, positive quantity, test environment, requesting team, scenario or release identifier, result destination, and approved limits. Validate those fields and calculate the expected provider credits before creating an external task.

Reject unsupported providers, missing ownership, quantities above the configured ceiling, or requests that exceed the test budget. The integration should make unsafe input visible instead of silently correcting it into different work.

  • Provider allowlist
  • Quantity and credit ceilings
  • Environment and scenario ID
  • Request and result owners
  • Secure destination reference
02 · IDEMPOTENT CREATION

Persist one logical key before the first network call.

A timeout does not prove that no task was created. Generate an idempotency key for the internal test job, persist it with the canonical provider and quantity, and reuse it while resolving uncertainty.

When the API returns a MailMaker task ID, store it beside the internal job and key. If the same key is later paired with a different payload, stop and surface a conflict rather than changing the existing request or creating ambiguous duplicate work.

03 · ASYNCHRONOUS STATES

Map the external task lifecycle into durable internal state.

Account creation is asynchronous. Model queued, processing, completed, partial, and failed explicitly instead of keeping a request open or inferring completion from elapsed time.

Persist last known state, next-check time, poll count, and maximum task age. A worker restart should resume the planned schedule rather than forgetting the task or creating a rapid polling loop.

04 · BOUNDED POLLING

Poll with backoff, jitter, a deadline, and stop conditions.

Retrieve the task at a conservative interval, increase the delay while it remains non-terminal, and add jitter when many test jobs run together. Stop polling immediately when the task reaches completed, partial, or failed.

When the maximum age or attempt limit is reached, move the internal job to manual review. Continuing forever hides incidents and consumes capacity without producing a trustworthy test result.

  • Persist next-check time
  • Back off repeated checks
  • Add jitter for concurrent workers
  • Stop on terminal states
  • Escalate beyond the deadline
05 · RESULT RECONCILIATION

Release output only after task and budget reconciliation.

At terminal state, retrieve the authoritative task and compare provider, requested quantity, successful count, failed count, final credits, and returned reservations with the internal job. Do not calculate final cost from requested quantity alone.

A partial task can provide useful test accounts and an unresolved remainder. Publish the accepted successful results to the secure destination, then require an explicit decision before submitting replacement work.

06 · SECRET-SAFE INTEGRATION

Separate orchestration metadata from credential retrieval.

Most logs need task ID, provider, state, counts, timestamps, error class, and correlation ID. They do not need API keys, authorization headers, passwords, recovery data, or complete export rows.

Use separate access for test and live environments, scope API keys to the minimum workflow, and restrict final result retrieval. The test system should reference a controlled result location rather than copying credentials into ordinary observability or defect systems.

07 · PRODUCTION GATE

Exercise failure paths before enabling unattended volume.

Test invalid input, insufficient balance, a timeout after submission, repeated non-terminal responses, a worker restart, polling deadline, partial completion, unavailable result storage, and manual cancellation. Confirm that each path stops, retries, or escalates according to a named rule.

Enable larger automated quantities only after the real provider, budget, result destination, and receiving test workflow have passed a representative end-to-end task.

QUESTIONS

What teams ask before they start.

Can a test suite create accounts synchronously?−

The recommended model is asynchronous. Create a durable task, store its ID, and let a worker observe explicit state rather than holding a test request open until provider work finishes.

How does the integration prevent duplicate tasks?+

Persist one idempotency key for the logical test job before submission and reuse it when resolving the same uncertain request. A genuinely new approved job receives a new key.

How frequently should task status be checked?+

Use bounded polling with a conservative interval, backoff, jitter, a maximum age, and immediate stop on completed, partial, or failed.

Should the status worker receive raw account credentials?+

Not automatically. Keep orchestration metadata separate from final credential retrieval and grant each component only the access its role requires.

What happens when only part of the task completes?+

Reconcile and release accepted successful output, confirm that failed items consumed zero credits, and require an explicit decision for the unresolved quantity.

KEEP EXPLORING

Build the complete workflow.

Account creation API

Review the complete developer product workflow.

→API idempotency

Design durable keys and conflict handling.

→Task polling

Implement backoff, deadlines, and terminal states.

→
READY WHEN YOU ARE

Credits in. Accounts out.

Start with the provider already selected. If an item fails, its credits return automatically.

Create your first task →