Authentication & API keys

The header#

Every request sends the key in the Authorization header, exactly like this:

Authorization: Bearer dpfn_your_key_here

The literal Bearer prefix, one space, then the key. Keys always start with dpfn_. Anything else — a missing prefix, a stray newline, an X-Api-Key header — returns 401 { "error": "Unauthorized", "code": "unauthorized" }.

What a key grants#

A key is bound to one creator account and grants the full surface for that creator: vault read and write, drops, posts, earnings, balance, links and Telegram notification settings. There are no scopes and no expiry — a key works until the creator revokes it. Posts and drops created with a key are always authored by that creator.

Personal keys vs app keys#

The creator picks at generation time, and the choice is fixed for the life of the key:

• Personal — for the creator’s own scripts or AI agent. Runs at the personal rate tier, and all personal keys of one creator share a single budget, so minting more keys does not buy more throughput.
• App-bound — generated for an approved app. Runs at the app tier with a per-key budget, and identifies your software to Dropfans.

GET /me tells you which kind you hold — see Make your first call.

Revocation#

Creators revoke keys from the same screen they were generated on (Vault → API Connect). A revoked key returns 401 immediately and forever. Handle a 401 by asking the creator to reconnect, never by retrying in a loop.

Storage hygiene#

• Store keys encrypted at rest; decrypt only to make the request.
• Keep keys server-side. Never ship one in client code, a repo, or a shared chat.
• Never log the full key. If you must reference it, use the first 12 characters — that prefix is what the creator sees in their key list.

Next: Apps & approval or Rate limits.