Authentication

Every OpenTweet request, whether REST, MCP, or CLI, authenticates with a single API key. One key, no X developer account, no OAuth handshake. This page shows how to create a key, send it, verify it, and keep it safe.

1. Create an API key

Open your developer dashboard and generate a key. Every OpenTweet key starts with the ot_ prefix so it is easy to spot in logs and secret scanners. Copy it once and store it somewhere safe, the full key is only shown at creation time.

If you are starting from scratch, the quickstart walks you from a fresh key to your first post in a few minutes.

2. Send it on every request

Pass the key in the Authorization header as a Bearer token. This is the recommended form and works across the whole REST API at https://opentweet.io/api/v1:

bash
curl https://opentweet.io/api/v1/me \
  -H "Authorization: Bearer ot_your_key"

If a Bearer header is awkward in your setup, you can send the same key in the generic X-API-Key header instead:

bash
curl https://opentweet.io/api/v1/me \
  -H "X-API-Key: ot_your_key"

One key, three surfaces

The same ot_ key authenticates the REST API, the hosted MCP endpoint at https://mcp.opentweet.io/mcp, and the opentweet CLI. There is nothing separate to provision per client.

3. Verify a key

Send a GET to /me to confirm a key is live before you wire it into automation:

bash
curl https://opentweet.io/api/v1/me \
  -H "Authorization: Bearer ot_your_key"

# 200 OK confirms the key is valid.
# 401 Unauthorized means the key is missing, revoked, or malformed.

A 200 response means the key is valid. A 401 means it is missing, revoked, or malformed.

4. Rotate and revoke keys

Manage keys from the developer dashboard. To rotate, create a new key, deploy it to your app, then revoke the old one. To revoke, delete a key from the dashboard and it stops working immediately, so any request using it starts returning 401.

Rotate on a schedule

Because a single key can post to your X account, rotate keys periodically and revoke any key that may have been exposed. Rotation is zero downtime when you deploy the new key before revoking the old one.

5. Keep keys server-side

Treat your ot_ key like a password. Read it from an environment variable or a secret manager, and only ever send it from a backend you control:

javascript
// Read the key from an environment variable, never hard-code it.
const res = await fetch("https://opentweet.io/api/v1/posts", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.OPENTWEET_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ text: "Hello from my server.", publish_now: true }),
});

Never expose an ot_ key

Do not put a key in client-side code, a browser bundle, a mobile app, or a public repository. Anyone who reads it can post to your X account. If a key leaks, revoke it from the dashboard right away and issue a new one.

6. Rate limits

Requests are rate limited per API key, and the ceiling depends on your plan. Higher plans get higher throughput. If you hit the limit you will receive a 429 response, so back off and retry. For high-volume scheduling, prefer batch endpoints such as POST /posts/batch-schedule (up to 50 posts per call) over one request per post.

Next steps