Apps

Create and configure apps to access the X API

Apps are containers for your API credentials. Each app has its own keys, tokens, and settings.

---

App credentials

When you create an app, you can generate these credentials:

Credential	Use case
API Key & Secret	Authenticate with OAuth 1.0a. Used to sign requests or generate user tokens.
Access Token & Secret	Make requests on behalf of your own account (OAuth 1.0a).
Client ID & Secret	Authenticate with OAuth 2.0. Used for authorization code flow.
Bearer Token	App-only authentication for public data endpoints.

Choose OAuth 2.0 for new projects. It offers fine-grained scopes and is required for X API v2 user-context endpoints.

---

Creating an app

1. Open the Developer Console

   Go to console.x.com and sign in.

2. Click Create App

   Enter a name, description, and use case for your app.

3. Generate credentials

   After creation, generate the keys and tokens you need.

4. Store securely

   Save credentials immediately—they’re only shown once.

---

App permissions (OAuth 1.0a)

OAuth 1.0a apps have three permission levels:

Read only

• View posts, users, and public data
• Cannot post, like, or modify anything
• Cannot access Direct Messages

Read and write

• All read permissions
• Post and delete posts
• Follow/unfollow users
• Like and repost
• Cannot access Direct Messages

Read, write, and DMs

• All read and write permissions
• Send and read Direct Messages

Changing permissions requires users to re-authorize your app to get new tokens with the updated scope.

---

OAuth 2.0 app types

When configuring OAuth 2.0, select your app type:

Type	Client	Use case
Web App	Confidential	Server-side applications that can securely store secrets
Automated App / Bot	Confidential	Bots and automated services running on servers
Native App	Public	Mobile or desktop apps that can’t secure secrets
Single Page App	Public	Browser-based JavaScript apps

Confidential clients receive a Client Secret. Public clients use PKCE only.

---

Callback URLs

Callback URLs (redirect URIs) are required for OAuth flows. After a user authorizes your app, they’re redirected to your callback URL with an authorization code.

Requirements

• Add callback URLs to your app’s allowlist in the Developer Console
• URLs must match exactly (including trailing slashes)
• Maximum of 10 callback URLs per app
• Use https:// in production
• For local development, use http://127.0.0.1 (not localhost)

Disallowed protocols

These protocols cannot be used: javascript, data, file, ftp, mailto, telnet, and other non-standard schemes.

Full list of disallowed protocols

vbscript, javascript, vbs, data, mocha, keyword, livescript, ftp, file, gopher, acrobat, callto, daap, itpc, itms, firefoxurl, hcp, ldap, mailto, mmst, mmsu, msbd, rtsp, mso-offdap, snews, news, nntp, outlook, stssync, rlogin, telnet, tn3270, shell, sip

---

Best practices

Use separate apps

Create different apps for development, staging, and production.

Rotate credentials

Regenerate keys periodically and if you suspect a compromise.

Minimal permissions

Request only the permissions your app actually needs.

Monitor usage

Check the Developer Console regularly to track API usage.

---

Automated account labels

If your app runs a bot account, you can label it as automated:

1. Go to your bot account’s Settings
2. Select Your account → Automation
3. Link your managing account

This builds trust with users and distinguishes your bot from spam.

---

Troubleshooting

Callback URL not approved error

Ensure your callback URL is exactly as registered in the Developer Console, including protocol and any trailing slashes. HTTP-encode the URL when passing it as a query parameter.

{
  "errors": [{
    "code": 415,
    "message": "Callback URL not approved for this client application."
  }]
}

App suspended

If your app shows as suspended, check your email for a notice from the X platform team. Use the Platform Help Form to appeal.