Authenticating Requests

Most Meetup API endpoints require member authentication to protect access to privacy and to personalize responses.

Using OAuth 2 ¶

The Meetup API provides support for OAuth 2. We require HTTPS for all API access. If your application does not use HTTPS, our servers will respond with a 400 error and a message asking you to do so.

We provide implementations of both the server and implicit protocol flows. We provide the following endpoints for both where necessary.

Redirect URIs

Before you can use OAuth 2 for user authorization, you need to either register a new OAuth consumer or add a redirect_uri to your existing consumer by clicking the edit link next to you consumer's listing. The redirect_uri you register for a given client will be used to validate future oauth2 requests.

This uri is used as a basis for validating the address authorization requests will redirect a member to after granting or denying access to your app.

If provided, the redirect URL's host and port must exactly match the callback URL. The redirect URL's path must reference a subdirectory of the callback URL.

CALLBACK: http://example.com/path

GOOD: http://example.com/path
GOOD: http://example.com/path/subdir/other
BAD:  http://example.com/bar
BAD:  http://example.com/
BAD:  http://example.com:8080/path
BAD:  http://oauth.example.com:8080/path
BAD:  http://example.org
      

Server Flow ¶

This flow is suitable for applications that are capable of securely storing consumer secrets.

Requesting Authorization ¶

https://secure.meetup.com/oauth2/authorize
  ?client_id=YOUR_CONSUMER_KEY
  &response_type=code
  &redirect_uri=YOUR_CONSUMER_REDIRECT_URI

Requesting Access Token ¶

https://secure.meetup.com/oauth2/access

client_id=YOUR_CONSUMER_KEY
&client_secret=YOUR_CONSUMER_SECRET
&grant_type=authorization_code
&redirect_uri=SAME_REDIRECT_URI_USED_FOR_PREVIOUS_STEP
&code=CODE_YOU_RECEIVED_FROM_THE_AUTHORIZATION_RESPONSE

{
  "access_token":"ACCESS_TOKEN_TO_STORE",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"TOKEN_USED_TO_REFRESH_AUTHORIZATION"
}

Make authenticated requests

Server Flow with User Credentials ¶

This is currently only available to Meetup Pro users

Use this flow when you want to write a program that uses the Meetup API using your own user credentials.

To use this flow, your application should be capable of securely storing consumer secrets and the username and password and must make all requests using HTTPS. Additionally, all requests should include Accept: application/json in the header.

Requesting Authorization¶

https://secure.meetup.com/oauth2/authorize
  ?client_id=YOUR_CONSUMER_KEY
  &redirect_uri=YOUR_CONSUMER_REDIRECT_URI
  &response_type=anonymous_code

{
  "code": "SINGLE_USE_AUTHORIZATION_CODE"
}

Requesting Access Token ¶

https://secure.meetup.com/oauth2/access?
  client_id=YOUR_CONSUMER_KEY
  &client_secret=YOUR_CONSUMER_SECRET
  &grant_type=anonymous_code
  &redirect_uri=SAME_REDIRECT_URI_USED_FOR_PREVIOUS_STEP
  &code=CODE_YOU_RECEIVED_FROM_THE_AUTHORIZATION_RESPONSE

{
  "access_token":"ACCESS_TOKEN_TO_STORE",
  "refresh_token":"TOKEN_USED_TO_REFRESH_AUTHORIZATION"
  "member":{
    ...
  }
  "token_type":"bearer",
  "expires_in":3600,
}

Request Access Token Using Your Credentials¶

https://api.meetup.com/sessions?
  &email=YOUR_EMAIL
  &password=YOUR_PASSWORD

Implicit Flow ¶

This flow is suitable for JavaScript based browser clients.

Requesting Authorization and Receiving Access Token ¶

https://secure.meetup.com/oauth2/authorize
  ?client_id=YOUR_CONSUMER_KEY
  &response_type=token
  &redirect_uri=YOUR_CONSUMER_REDIRECT_URI

Make authenticated requests

Refreshing Your Access Token ¶

Once received, an access_token may expire. You can refresh the access_token at any time and without involving the user by making a token refresh request. Note, this requires client credentials which users of the implicit flow should not be storing.

Refreshing Token ¶

https://secure.meetup.com/oauth2/access

client_id=YOUR_CONSUMER_KEY
  &client_secret=YOUR_CONSUMER_SECRET
  &grant_type=refresh_token
  &refresh_token=REFRESH_TOKEN_YOU_RECEIVED_FROM_ACCESS_RESPONSE

{
  "access_token":"ACCESS_TOKEN_TO_STORE",
  "token_type": "bearer",
  "expires_in":3600,
  "refresh_token":"TOKEN_USED_TO_REFRESH_AUTHORIZATION"
}

Make authenticated requests

Making Authenticated Requests ¶

After successfully obtaining member authorization and an access_token you may now make authenticated API requests using HTTPS by supplying the token value in an Authorization header prefixed with bearer and a space.

curl -H "Authorization: Bearer {access_token}" https://api.meetup.com/members/self/

User Deauthorization ¶

At any time, a user may choose to revoke access to your application here. This will invalidate any access credentials your application may have been provided for that user.

In order to re-obtain authorization, your application will need to re-request authorization from the user.

Access tokens received from the implicit oauth2 flow will also expire, regardless of the ageless scope, when the user logs out of meetup.com.

Mobile-Optimized Authorization Display ¶

In some cases, you may want to display Meetup's authorization page in a more compact way for mobile devices or a JavaScript popup window. For these cases just append the query parameter set_mobile with a value of on.

User signup ¶

Besides asking the user to log in or to authorize your application, a user may be asked to create an account if they are not already a member. If they choose to do so through they are sent an email verification link which. Once verified, if you are using the server flow, Meetup will redirect the user to your application with the user granted authorization.

If you are implementing an implicit client, you should be aware of this in your design. Typically these clients will open a popup window to display the Meetup login and authorization forms. If the user chooses to create an account through Meetup, after the verification step, the user will only be sent to meetup.com and not redirected to your app which, by that time will most likely have lost the local state need to handle in the incoming request in a new window.

Member registration as part of an OAuth flow can be helpful if the member wishing to log into your application is not a member on Meetup. It can also add complexity. Applications may opt out of registration by providing an additional parameter named suppress, who's value is set to reg. This will have the effect of suppressing a link to register for a new Meetup account if your application user is not already a member on Meetup. You should be clear in any of your application's interstitial views prior to redirecting your user to Meetup that your application requires an account on meetup.com.

Permission Scopes ¶

OAuth 2 includes the concept of access scopes which further restrict access of a consumer to a Meetup user's data. All clients are implicitly configured with the basic scope.

To request this additional scope, pass a value of one or more scope names using + space encoding in the scope request parameter to the url for obtaining authorization, https://secure.meetup.com/oauth2/authorize.

Below is a table of the available Meetup API scopes names an their associated permissions.

Note, when making a request you should be able to see which scopes have been enabled and are required using in the following headers

X-OAuth-Scopes: basic, reporting
X-Accepted-OAuth-Scopes: basic, reporting

You should also be able to see which scopes are required in the method documentation.