Authentication

There are no API keys to create. The first write returns a one time approval link, you click it once, and the agent is bound to your account.

Open in Claude

Nick Launches does not issue API keys from a settings page. An agent asks for access at the moment it needs it, you approve that request once in a browser you are already signed into, and the connection is bound to your account from then on.

That design exists for one reason: a long lived secret pasted into an agent config is a secret that ends up in a transcript, a screenshot or a repository. Pairing in the browser keeps it out.

What needs credentials

Capability	Credentials
`search_products`, `get_product`	None
`list_launch_directories`	None
`check_launch_readiness`	None, rate limited
`submit_product`	Connection
`get_my_launches`	Connection
`GET` endpoints under `/api/v1/`	None
`POST /api/v1/submissions/`	Bearer token
`GET /api/v1/me/launches/`	Bearer token

The browser link flow

1
The agent calls a write tool with no connection
It does not error. The server starts a pairing and returns readable text with a link:
```
This session is not connected to a Nick Launches account yet.
Open https://nicklaunches.com/connect/?code=8F2K-QT4M, approve the request,
then run this tool again.
```
The code is short lived. If you leave it sitting, ask the agent to try again and it issues a new one.
2
You approve it
The page at /connect/ shows which client is asking, using the name the MCP client sent during initialize, so "Claude Code" or "Cursor" appears rather than an opaque id. If you are not signed in you are sent through sign in first and returned to the same approval.
3
The session is bound
Approval attaches your user to the MCP session id the server issued at initialize. The agent retries the tool and it now runs as you. Nothing secret is passed back through the agent.

Rerunning the tool after approval is the whole flow. If a client re-establishes its session, it pairs again, which takes one click.

Bearer tokens, for scripts

The approval page also shows a bearer token once, for callers that are not MCP clients:

nl_ct_9f2c41e0b7d84a5f8c3e6d21a90b7fd4

Send it on REST requests:

curl -X POST https://nicklaunches.com/api/v1/submissions/ \
  -H "Authorization: Bearer nl_ct_9f2c41e0b7d84a5f8c3e6d21a90b7fd4" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com"}'

The token is shown once.

Only a hash of it is stored, so it cannot be shown again and it cannot be recovered from support. If you lose it, revoke the connection and pair again.

Treat it like a password. Put it in an environment variable, never in a repository, and never paste it into an agent prompt: an MCP client does not need it, because the session binding already covers it.

Managing connections

Every connection is listed at /profile/connections/ with its label, when it was created and when it was last used. Revoking one takes effect immediately: the next call from that session or with that token falls back to pairing, and the agent will show you a fresh approval link.

Revoke a connection when you stop using a client, when you finish a one off script, or any time a machine leaves your control.

Errors you may see

UNAUTHORIZED

No connection and no valid bearer token. On MCP this normally appears as the pairing message rather than an error. On REST it is a 401.

FORBIDDEN

The connection is valid but is not allowed to touch that resource, for example another maker's launch. A 403.

The full list is on Errors.

What approval does not grant

Approving a connection lets an agent read your launches and open drafts under your account. It does not let it publish a launch, choose a plan, choose a week, spend money, change your profile or act on anyone else's products. See submit_product for exactly where the agent stops.

Was this page helpful?