← blog

The Zero-Auth API

Every disposable email API I looked at before building Agent Burner required me to create an account, verify my email, generate an API key, store it somewhere, and pass it with every request.

For a service whose entire purpose is creating throwaway inboxes that last an hour.

The pattern

Here’s what signing up for a disposable email API typically looks like:

  1. Go to the website
  2. Create an account with your email
  3. Verify your email (ironic)
  4. Navigate to the API settings
  5. Generate an API key
  6. Store the key in your environment variables
  7. Pass the key in every request header

Then you can create a disposable inbox. The inbox lives for an hour. The API key lives forever. You’ve created a permanent credential to manage temporary resources.

If the key leaks, someone has access to every inbox you create until you notice, log in, and revoke it. If you forget to rotate it, it accumulates access scope over time. If the service gets breached, every key in their database is compromised.

All of this for an inbox that auto-deletes in 60 minutes.

The alternative

curl -X POST https://api.agentburner.com/inbox
# {"address":"[email protected]","key":"550e8400-..."}

No account. No API key. No headers. The response includes a UUID — the inbox key. That’s your credential. It’s scoped to one inbox, expires with that inbox, and if it leaks, the worst that happens is someone reads a disposable email that’s about to be deleted anyway.

The security model is: the capability IS the credential. Creating an inbox gives you a key that accesses only that inbox. No master key that grants access to everything. No account that accumulates permissions. No credential that outlives the resource it protects.

Why APIs default to API keys

API keys solve real problems. They enable rate limiting per customer. They enable billing. They enable access logging. They enable revocation. For a persistent service with long-lived resources, this makes sense.

But disposable email isn’t a persistent service. The resources are designed to disappear. There’s no customer relationship to manage — the agent creates an inbox, uses it, and moves on. There’s no billing to track because the cost of a disposable inbox is negligible. There’s no revocation needed because the credential self-destructs.

API keys on a disposable email service exist because that’s how APIs are supposed to work, not because the problem requires it. It’s cargo culting.

What zero-auth enables

When there’s no account to create, an agent can start using the API without a human ever configuring anything. No one needs to sign up, generate a key, and paste it into an environment variable before the agent can receive email.

This matters more than it sounds. The current model for giving an agent email access is:

  1. Human signs up for an email API
  2. Human generates an API key
  3. Human configures the key in the agent’s environment
  4. Agent can now create inboxes

With zero-auth, the agent skips to step 4. It discovers the API from documentation, calls POST /inbox, and has a working email address. No human setup. No credential chain. No configuration drift when someone forgets to rotate a key.

For persistent agents running on VPSes — OpenClaw, Hermes, whatever — this means the agent can autonomously acquire disposable email whenever it needs it. No dependency on a human having set up credentials in advance.

The tradeoffs

Zero-auth has real costs.

No per-user rate limiting. Without an API key, rate limits are per-IP. An agent behind a shared proxy gets a shared rate limit. For a high-volume service, this would be a problem. For a disposable email API where a typical agent creates a few inboxes per day, per-IP limiting at 10 creations per minute is more than enough.

No billing. You can’t charge per inbox if you don’t know who’s creating them. Agent Burner is free. If it ever needs to make money, a paid tier with API keys could sit alongside the free tier — but the free, zero-auth path should always exist.

No audit trail. You can’t trace inbox creation back to a specific customer. You can trace it to an IP address, which is sufficient for abuse mitigation but not for customer analytics.

No revocation. If someone abuses the service, you can block their IP but you can’t revoke a specific customer’s access. In practice, disposable email abuse is self-limiting — the inboxes expire, the addresses rotate, and there’s no outbound email to spam with.

These are real tradeoffs. They’re acceptable because the resource being protected is temporary. A disposable inbox that auto-deletes in an hour doesn’t need the same security apparatus as a persistent mailbox.

The principle

Match the credential’s lifetime to the resource’s lifetime. If the resource is permanent, the credential should be permanent (and managed, rotated, scoped). If the resource is temporary, the credential should be temporary — and ideally should BE the resource.

An inbox key that expires when the inbox expires. A credential that can’t outlive what it protects. No state to manage, no secrets to rotate, no accounts to audit.

Not every API needs an API key. Some just need a good UUID.