AI Content Drop API Authentication

The short version

Send Authorization: Bearer acd_live_… on any request that touches an account or spends credits. Everything else — the model catalogue, cost quotes, articles, the GraphQL schema, the MCP read tools — works with no credential at all.

If the human has no account yet

An agent cannot finish a signup — it has no mailbox and cannot accept terms on someone's behalf — but it can start one and hand the person a single clear step.

POST https://aicontentdrop.com/v1/auth/register
Content-Type: application/json

{ "email": "[email protected]" }

Returns 202 with status: "human_action_required" and a message_for_human line written to be repeated verbatim. The person receives a sign-in link; opening it creates the account, confirms the address, and releases the free credits.

There is no password parameter, and that is deliberate. An agent holding a user's password is a credential-custody problem that no rate limit fixes, so the flow is magic-link only.

Credits are released on confirmation, not on signup. An account created this way holds 0 credits until the human clicks the link, at which point the 10 free credits appear. That is what stops programmatic signup from being a free-credit faucet — an IP limit alone would not, because IPs rotate.

An address that already has an account gets exactly the same response, so this endpoint cannot be used to test who is registered here.

Limited to 5 registrations per hour per IP; a 429 carries Retry-After.

While you wait

Do not block on the human. These need no account at all:

Getting a key

A key belongs to a person, not to an agent, and only a signed-in human can mint one:

1. Sign in at https://aicontentdrop.com.
2. Open Settings → Integrations.
3. Create a key. It is shown once. Store it; we keep only a hash.

Keys are prefixed acd_live_. A key carries the plan, credit balance, and rate ceiling of the account that owns it. Revoking a key is immediate.

Discovering all of this from one request

An agent that hits a protected endpoint without a credential gets a 401 that says where to look:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="AI Content Drop",
  resource_metadata="https://aicontentdrop.com/.well-known/oauth-protected-resource"

• /.well-known/oauth-protected-resource — RFC 9728 protected-resource metadata
• /.well-known/oauth-authorization-server — RFC 8414 authorization-server metadata
• /auth.md — the same thing as prose, in the seven sections agents expect: discover, pick a method, register, claim, use, errors, revoke

Agent self-registration

An agent with no human behind it can register for a read-scoped token:

curl -sX POST https://aicontentdrop.com/agent/auth/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"my-agent"}'

That token raises read rate limits. It cannot generate — generation spends money, and money needs an account a person owns. The endpoints are POST /agent/auth/register, /agent/auth/claim, and /agent/auth/revoke; only anonymous identity is supported, which the metadata says explicitly rather than implying more.

Verifying us

Requests our own crawlers make to other sites are signed with Ed25519 (RFC 9421 HTTP Message Signatures, Web Bot Auth). The public key is at /.well-known/http-message-signatures-directory, and the same key backs the did:web:aicontentdrop.com identity in /.well-known/did.json that our ARD catalogue entries are signed against.

What a key can reach