> For the complete documentation index, see [llms.txt](https://stonkfun.gitbook.io/stonkfun-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stonkfun.gitbook.io/stonkfun-docs/developer-api/authentication.md).

# Authentication and non-custody

There is no API key. There is nothing to sign up for, no plan to buy, and no credential to rotate.

## Why not

A launch is authorised by your own wallet's signature on the fee payment, which is stronger proof than any key we could issue. So we do not issue one.

Keys were never a security control here anyway. Launching is authorised by the signature, and a self-serve key can be minted as fast as an abuser can rotate an address. What remains is the part that was actually doing work: a per-minute ceiling that stops a runaway client.

The OpenAPI document carries no security schemes as a result. A launch's authorisation travels in the request body as a signed transaction rather than in a header, so there is nothing for OpenAPI's auth model to describe, and generated clients come out with no credential parameter.

## Non-custodial throughout

The platform never asks for, accepts or stores a private key.

| Guarantee                        | How it is enforced                                                                                |
| -------------------------------- | ------------------------------------------------------------------------------------------------- |
| You sign the launch fee locally  | `/prepare` returns an unsigned transaction; you sign it and return it                             |
| No endpoint signs on your behalf | No platform key is a signer on anything a user supplies                                           |
| A fee claim can only pay you     | The transaction is only valid signed by the Fee Key holder, and pays that wallet's own accounts   |
| Submit is not a general relay    | The prepared transaction is recorded before relaying, and the instructions are checked against it |

## Why preparing a claim needs no credential

`POST /tokens/{mint}/fees/claim/prepare` takes a `creatorWallet` and hands back an unsigned transaction, with no proof that you are that wallet.

That is safe, and deliberately so. The transaction is only valid when signed by the wallet holding that launch's Fee Key NFT, and it pays that wallet's own accounts. For a token you do not own, you get a transaction you cannot make valid.

Preparing is not a privileged action. The privileged part is signing, and that is exactly the thing the platform cannot do.

## The one place a password is used

`mode: 'reward'` requires an admin password header while reward launches are restricted to admins. Without it, `/prepare` answers `403`.

That is a product restriction rather than an authentication scheme. It lets the real launch path be exercised with real launches before the option is opened to everyone.

## Rate limiting identity

Limits are keyed by client IP address. There are no tiers, no plans, and nothing to raise by paying. See [Rate limits](/stonkfun-docs/developer-api/rate-limits.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://stonkfun.gitbook.io/stonkfun-docs/developer-api/authentication.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.