HTTP Basic Authentication

How it works

Most of Twitter’s Enterprise APIs require HTTP Basic Authentication. This consists of a valid email address and password combination passed as an authorization header for each API request.

Prerequisite

Access to the enterprise console: https://console.gnip.com/.

You will need

Username and password. This username and password combination is the same login credentials (email address and password) used to log in to the enterprise console.

OAuth 1.0a (user context)

How it works

OAuth 1.0a (sometimes also referred to as “user context authentication”) allows you to make API requests on behalf of a Twitter user. This authentication method allows you to send your developer App’s Consumer Keys (API Key and Secret), alongside a set of user access Tokens (Access Token and Secret), as part of the authorization header in the API request. 

While the Consumer Keys give the API context about the developer App that is sending a request, the Access Tokens provide context about the Twitter user on behalf of whom the App is sending the request. 

All write actions and all reading of protected data using the Twitter API require OAuth 1.0a, and the Access Tokens must belong to the owning user. For example, in the case of posting a Tweet, the Access Tokens must belong to the user on behalf of whom you are posting the Tweet. Similarly, if you are accessing private engagement metrics with the Engagement API, the Access Tokens must belong to the user who owns the Tweet(s) and related protected data. 

If the user behind a request is yourself (in other words, the Twitter account that owns the developer App) the required Access Tokens can be generated directly from within the developer portal (under the “Keys and tokens” tab for your developer App).

For all other Twitter accounts, users must first authorize your developer App for access. A user can grant your developer App access by undergoing the 3-legged OAuth flow, which in turn allows you to obtain the user’s Access Tokens. You can then use these Access Tokens to authenticate your request and make a request on behalf of the user.

Information on how to obtain a user’s Access Tokens is included in the article OAuth 1.0a: how to obtain a user’s access tokens. 

Information on how to authorize a request using OAuth 1.0a can be found in our documentation.

Prerequisite

• An approved Twitter developer account (if you don’t have one, you can apply for access).

• A Twitter developer App. You can create a new developer App or access existing ones in the Projects & Apps section of your developer portal.

You will need

1. Consumer Keys (API Key and Secret).

• These can be generated in your developer portal, under the “Keys and tokens” tab for your developer App.

2. User Access Tokens (Access Token and Secret). 

• If you are making a request on behalf of your own account, these can be generated in your developer portal, under the “Keys and tokens” tab for your developer App.

• If you are making a request on behalf of another user, you can obtain these Access Tokens via the 3-legged OAuth flow. You can read more about how to do this below: OAuth 1.0a: how to obtain a user's access tokens.

   

OAuth 2.0 Bearer Token (application-only)

How it works

OAuth 2.0 Bearer Token allows you to make API requests on behalf of your Twitter developer App. This authentication method is also sometimes referred to as “application-only authentication” because the credentials you send as part of the request give the API context about your developer App. Compared to OAuth 1.0a user context authentication, OAuth 2.0 Bearer Token does not involve any Twitter user(s). This authentication is typically used for read-only access to publicly available information (for example, accessing public Tweets).

Prerequisite

• Approved Twitter developer account (if you don’t have one, you can apply for access).

• A Twitter developer App. You can create a new developer App or access existing ones in the Projects & Apps section of your developer account.

You will need

Consumer Keys (API Key and Secret) or a Bearer Token. These can be generated in your developer portal, under the “Keys and tokens” tab for your developer App.