Authentication

Every request to https://api.pump.fun/v1 must carry an API key. Keys are checked at the origin on every request; there is no session, cookie or OAuth flow on this host.

Because there is no signed-in user, viewer-relative fields are never populated on this host. Response schemas in the reference still list them (viewer.followsYou, dmEligible, mutuals, isFollowing and the like, which the pump.fun web app fills from the session); on api.pump.fun they are always absent, null or false. Do not build on them.

Headers

Send the key in one of two headers. Prefer Authorization: Bearer; x-api-key is an alias for clients that cannot set Authorization. The OpenAPI document declares a single security scheme, bearer, and mentions the alias in that scheme’s description, so a client generated from it sends Authorization: Bearer.

Authorization: Bearer pf_live_...

x-api-key: pf_live_...

Situation	Result
Neither header	401 API_KEY_REQUIRED
Both headers, different values	Refused as malformed: 401 API_KEY_INVALID
x-api-key sent more than once	Refused as malformed: 401 API_KEY_INVALID
Authorization with a scheme other than Bearer	Refused as malformed: 401 API_KEY_INVALID
Key in a query string	Not read there (and it would end up in logs); treated as no key
Any request header starting with x-pump-api-	Dropped before routing; do not rely on them
pump.fun session cookie or user JWT sent to the API host	400 API_CREDENTIAL_NOT_ALLOWED
API key sent to the pump.fun web hosts	400 API_CREDENTIAL_NOT_ALLOWED; keys work only on api.pump.fun

Both headers are removed from the request once the key has been read, so nothing behind the key check ever sees it.

Key shape

pf_live_ + 43 base62 characters + 6 base62 characters   (57 characters total)

The 43-character body is 32 random bytes in base62 (0-9A-Za-z); the trailing 6 characters are a CRC-32 checksum of the body. Clients do not need to validate the checksum, but secret scanners can match keys on the pf_live_ prefix and the fixed length. A key that fails the prefix, length, character-set or checksum check is refused before any lookup (401 API_KEY_INVALID), and the response does not say which check failed.

The developer console displays a key as its 12-character prefix (pf_live_ plus four characters) and its last four characters. That display form is safe to put in a support ticket; the full key is not.

Scopes

Each key carries a set of scopes. A route outside the key’s scopes answers 403 API_SCOPE_FORBIDDEN with requiredScope in the body. See Scopes.

Rotation

Rotating a key in the developer console issues a sibling key with the same name, scopes and limits. The old key is not cut off at once: it enters a grace window during which both keys work, and is revoked automatically when the window ends.

1. Rotate: choose the grace window (1 hour to 7 days; the default is 24 hours) and copy the new key once.
2. Deploy the new key within the window.
3. Optionally revoke the old key early once nothing uses it. Otherwise it stops working at the end of the window.

During the window the old key shows as rotating in the console with the instant it stops being served. A rotating key does not count against your organisation’s key limit, so rotation is always possible even when the limit is reached. A key that is already rotating cannot be rotated again (409 API_KEY_ROTATING); rotate its successor instead.

Revocation

Revoking a key takes effect on the next request (403 API_KEY_REVOKED). The same applies when an organisation is suspended (403 API_ORG_SUSPENDED) or when the pump.fun team changes a key’s scopes or limits: the change is visible on the next call.

Browser origins get keys revoked

The API is server-to-server. It sends no CORS headers for third-party origins, and a key that arrives with a browser Origin header is logged and flagged to the pump.fun team, who revoke it. The reference page’s “Try it” is disabled for the same reason; the snippets it generates are meant to be run from a terminal or a backend.

If a key leaks

Revoke it in the console immediately, then create a new one. Every call is attributed to a key id (returned to you as the x-pump-api-key-id response header), so support can tell you what a leaked key was used for.