Log inStart creating →
PROTON BOT + API

A Proton account creator bot built around tasks, not blind scripts.

Connect Proton account provisioning to an internal tool or approved automation while keeping every request, retry, state change, and result observable.

Create Proton →See how it works
✓ Failed items use zero credits  ·  No subscription
CREATE TASK
ProviderProton
Quantity100 accounts
Estimated total200 credits
Failed? Credits returned.
THE SHORT VERSION

Your bot creates one task, stores its ID, polls explicit state with a deadline, and reconciles the final Proton result before downstream use.

Request safetyIdempotent

Retry without intentionally duplicating the order

Task updatesPolling

Retrieve explicit status by task ID

Provider rate2 credits

Per successful Proton account

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 · AUTOMATION WITH STATE

What a useful Proton account creator bot actually does.

Proton automation benefits from the same task contract as other providers while keeping its provider-specific price and results isolated from unrelated batches.

The automation layer submits a validated provider and quantity, saves the idempotency key with the returned task ID, and maps MailMaker states to an internal job. That makes retries and recovery explicit instead of relying on a browser session or elapsed time.

  • Validate provider and quantity before submission
  • Persist task and idempotency identifiers together
  • Model queued, processing, partial, completed, and failed
  • Retrieve the authoritative final result
02 · PROVIDER-SPECIFIC AUTOMATION

Keep Proton credentials out of polling logs and observability tools.

The bot should use task-status polling only to observe progress, not treat polling responses as credential storage. Fetch the authoritative final result from the approved worker and write it directly to the destination chosen for sensitive account data.

Logs should retain task ID, state, counts, duration, and error category while excluding passwords and recovery data. Redaction should be enforced in code because a written policy alone cannot stop accidental debug logging.

  • Metadata-only status checks
  • Direct write to the secure destination
  • Credential redaction in application logs
  • Short-lived retrieval permission
03 · PROGRAMMATIC GUARANTEE

Reconcile successful output and returned credits from the same task.

The integration should never calculate the final Proton charge from requested quantity alone. Retrieve the completed task, use the successful count for charged output, and verify that every failed item consumed zero credits or had its reservation returned.

This credit-back guarantee is deterministic enough to encode in an automated reconciliation rule. If task counts and ledger movement do not agree, stop downstream release and send the task ID to support rather than inventing a replacement request.

  • Final charge follows successful_count
  • Failed items use zero credits
  • Partial tasks remain valid results
  • Ledger mismatch triggers manual review
04 · BOUNDED STATUS POLLING

Poll the task deliberately; stop when it reaches a terminal state.

Store the returned task ID and retrieve its status on a bounded schedule. Increase the interval while a task remains queued or processing, add jitter when many workers run at once, and stop polling when the state becomes completed, partial, or failed.

After a terminal response, compare requested, successful, failed, and credits used. This final reconciliation prevents elapsed time or a stale local state from becoming the permanent business record.

  • Store the task ID before polling
  • Use backoff and jitter
  • Stop on completed, partial, or failed
  • Fetch and reconcile the final result once
05 · AUTOMATION BOUNDARIES

Keep Proton automation authorized and reviewable.

Restrict access to Proton result exports and define a removal policy before a high-volume task begins.

A Proton bot should write result data only to the designated secure destination and keep raw credentials out of polling logs and general observability systems.

A bot should reduce repetitive orchestration, not remove accountability. Limit API-key scope, isolate test and live environments, log the requesting system, and keep credential exports out of application logs.

06 · REQUEST CONTRACT

Validate the job before it becomes an external task.

The integration should accept a known internal request with a Proton provider value, positive quantity, approved maximum, internal owner, environment, and correlation ID. It should calculate the expected 2-credit rate before sending anything to MailMaker.

Reject unknown providers, missing owners, quantities outside the configured ceiling, and jobs that would exceed the credit budget. Persist the idempotency key before the first network call so the same logical job can be recovered after a timeout.

  • Provider allowlist
  • Quantity and credit ceilings
  • Owner and correlation ID
  • Durable idempotency key
  • Separate test and live credentials
07 · RETRY DECISION TREE

Treat timeouts, rejected requests, and failed tasks differently.

A validation error should be corrected before another request is sent. A network timeout is uncertain and should be resolved with the same idempotency key or by retrieving the existing task. A completed partial task is not a transport retry; it requires reconciliation and a decision about the unresolved quantity.

Use bounded retries with backoff for transient transport failures. Record the final outcome and stop automatically when the failure is permanent, the budget is exhausted, or a human decision is required. Infinite retry loops hide incidents and can multiply cost.

  • 400-series validation: fix the request
  • Timeout: recover the existing logical task
  • Rate limit: respect retry guidance
  • Partial task: reconcile before replacement
  • Permanent failure: stop and alert the owner
08 · POLLING SAFETY

Authenticate every status request and keep polling state durable.

Use a scoped API key for every task retrieval and keep it outside source code and logs. Persist the last known state, next-check time, and poll-attempt count so a worker restart does not create a rapid loop or lose track of an active task.

Treat repeated responses as normal. Change downstream state only when the authoritative task advances, and retrieve the final result once before marking the internal job complete.

  • Scoped API authentication
  • Durable next-check time
  • Maximum polling duration
  • State-change-aware processing
  • Final task retrieval
09 · PRODUCTION READINESS

Checklist for operating a Proton creator bot safely.

A Proton bot should write result data only to the designated secure destination and keep raw credentials out of polling logs and general observability systems.

Test repeated status responses, network timeouts, partial completion, insufficient balance, expired polling windows, and provider-specific rejection before enabling unattended production volume. Monitoring should expose task age, state, requested quantity, successful count, failed count, credit estimate, and owner without exposing raw credentials.

  • Scoped and rotatable API key
  • Idempotent task creation
  • Bounded polling with backoff
  • Budget and concurrency controls
  • Credential-safe logging
  • Manual recovery path
QUESTIONS

What teams ask before they start.

Should Proton credentials be included in polling logs?−

No. Poll only for task metadata, then route the final credentials directly to their authorized secure destination.

What is a Proton account creator bot?+

It is an integration that submits and monitors authorized Proton account-creation tasks through an API instead of requiring an operator to repeat dashboard steps.

How should the bot handle network retries?+

Reuse an idempotency key for the same logical request. If a timeout occurs, retrieve or safely retry the original task rather than creating an unrelated duplicate.

How does the bot detect completion?+

Store the task ID and retrieve its status with bounded polling. Stop when it reaches completed, partial, or failed, then reconcile the authoritative final result.

How are Proton automation costs and failures controlled?+

MailMaker returns the estimated credit requirement before execution. Proton costs 2 credits per successful account, while failed items consume zero credits and reserved credits return automatically.

KEEP EXPLORING

Build the complete workflow.

API overview

Review authentication, task states, and status retrieval behavior.

→Bulk Proton creator

Plan provider-specific batches and result handoff.

→Task polling implementation guide

Design backoff, stop conditions, retries, and reconciliation correctly.

→
READY WHEN YOU ARE

Credits in. Accounts out.

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

Create Proton →