The Meetup API provides a simple interface for accessing the Meetup platform from your own apps. It includes GET methods to query Meetup data, POST methods to create and alter resources, and streaming methods for realtime access to member activity.
Test your app with live Meetup data
Request to join this Meetup Group
Get updates on new features, announcements, and service advisories.
Follow @meetupapiGet your questions answered on the API mailing list.
The API is a set of core methods and a common request format. These are combined to form a URL that returns the information you want. Here's an example of an API call that lists moms groups near Williamsburg, Brooklyn.
http://api.meetup.com/groups1.xml2/?zip=11211&topic=moms3&order=members4&key=ABDE12456AB23244455
In addition, you can specify these parameters for more control:
Most requests must be authenticated. If no format is specified it defaults to json
. Details on the formats, parameters and ordering accepted by each method are listed below.
In addition, requests about a specific group can identify the group with either a group_id, or a topic and groupnum. The group_id can be retrieved from the id field from requests to the "Groups" method (detailed below), and the topic and groupnum can be found in the URL for the meetup group - for example, the group with the URL at http://volunteerism.meetup.com/167/ can be accessed with the parameters topic=volunteerism&groupnum=167.
The Meetup API supports the CORS specification which allows browser clients hosted on a domain other than api.meetup.com to communicate directly with the API.
The API uses OAuth consumer redirect uris to validate a request's origin, so you must be using OAuth to benefit from CORS. The suggested OAuth authorization scheme is the OAuth2 Implicit flow, which is tailored for browsers. Once a browser client recieves authorization and issues an HTTP request, the Meetup API will validate the request's Origin header with the consumers registered redirect URI in addition to the HTTP method used for the given API endpoint.
You can inspect which HTTP methods an API method supports issuing an OPTIONS request for the given method uri and origin. An example of the response headers is below.
curl -i -X OPTIONS -H 'Origin: http://consumerhost.com' 'https://api.meetup.com/2/member/self?access_token=TOKEN' HTTP/1.1 200 OK Access-Control-Expose-Headers: X-Meetup-server, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimt-Reset Access-Control-Allow-Origin: http://consumerhost.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Max-Age: 86400
The CORS specification is relatively new, but many browsers have already adopted it. You can find the current browser support here here.
Each API method has multiple ways you can request the data be returned as. All methods support json, and this is the default format used when you don't explicitly supply one. The other formats are supported when it makes sense for the type of data being requested.
JSON
JavaScript Object Notation. Learn more here.
XML
A simple XML format with the exact same fields as the json response.
KML
Keyhole markup language. Learn more here.
RSS
RSS 2.0. Learn more here.
ATOM
Learn more here.
The default character encoding for all API methods
going forward is UTF-8, while older API methods use
ISO-8859-1. To activate UTF-8 response encoding for all
methods, applications may supply in their requests an
Accept-Charset
header for UTF-8.
curl "http://api.meetup.com/2/open_events?topic=dogs&key=ABDE12456AB2324445" \
--header "Accept-Charset: utf-8"
The above command shows how to add the header to a request made with curl. If "utf-8" or "utf8" occurs anywhere in this header (case-insensitive) the response will be UTF-8 encoded. Otherwise, the default encoding for the particular API method is used.
If you request json
, and want to play with the API in a web browser -- callbacks are useful. Specifying a callback will allow you to populate sample data using a <script/> tag by returning javascript that calls the function you provide as a query parameter.
http://api.meetup.com/topics.json/?callback=gotIt&page=1&key=ABDE12456AB2324445
gotIt({"results":[...], "meta": {...}})
The context of a successful response to a query depends on the format it was requested in, though there are some broad similarities between the JSON and XML formats. Here's two samples:
curl 'http://api.meetup.com/topics.json/?key=ABDE12456AB2324445&page=1'
{
"results":[
{
"id":"4422",
"updated":"Mon Jun 26 15:01:05 GMT 2006",
"description":"Meet fellow Social Networkers near you! Come to a local Social Networking Meetup to make valuable social connections and cultivate relationships with other elbow-rubbers in your area.",
"name":"Social Networking",
"link":"http:\/\/socialnetwork.meetup.com\/",
"urlkey":"socialnetwork",
"members":"245701"
}
],
"meta":{
"id":"",
"title":"Meetup Topics",
"count":1,
"updated":"",
"description":"API for accessing meetup topics",
"next":"",
"link":"http:\/\/api.meetup.com\/topics\/",
"method":"Topics",
"total_count":3063,
"url":"http:\/\/api.meetup.com\/topics\/\/?order=members&key=1&page=1&format=json&desc=0&offset=0",
"prev":""
}
}
curl 'http://api.meetup.com/topics.xml/?key=ABDE12456AB2324445&page=1'
<?xml version='1.0' encoding='UTF-8'?>
<results>
<head>
<url>http://api.meetup.com/topics/?order=members&key=1&page=1&format=xml&desc=0&offset=0</url>
<link>http://api.meetup.com/topics/</link>
<total_count>3063</total_count>
<description>API for accessing meetup topics</description>
<title>Meetup Topics</title>
<count>1</count>
<next/>
<method>Topics</method>
<id/>
<updated/>
</head>
<items>
<item>
<updated>Mon Jun 26 15:01:05 GMT 2006</updated>
<members>245701</members>
<name>Social Networking</name>
<link>http://socialnetwork.meetup.com/</link>
<description>Meet fellow Social Networkers near you! Come to a local Social Networking Meetup to make valuable social connections and cultivate relationships with other elbow-rubbers in your area.</description>
<urlkey>socialnetwork</urlkey>
<id>4422</id>
</item>
</items>
</results>
As newer methods are introduced as part of the v3 API, response bodies will be simplified into what would normally be returned in the results
response property of previous API versions. Relevant request metadata, previously embedded in the meta
response body field, will now be encoded has HTTP headers with the response. The prev
and next
meta fields will now be encoded in a Link header. Link types will be annotated with a "rel" attribute.
$ curl -i 'http://api.meetup.com/dashing-whippets/boards?key=API_KEY' HTTP/1.1 200 OK Date: Wed, 10 Oct 2012 20:34:40 GMT Server: Apache-Coyote/1.1 X-Meetup-server: servername X-RateLimit-Limit: 200 X-RateLimit-Remaining: 199 X-RateLimit-Reset: 1349902800610 X-OAuth-Scopes: basic X-Accepted-OAuth-Scopes: basic Link: <http://api.meetup.com/dashing-whippets/boards?key=API_KEY&offset=1>; rel="next" Content-Type: application/json;charset=utf-8 Content-Length: 270 Vary: Accept-Encoding,User-Agent Connection: close [{...}]
Clients that wish to access the API using JSONP will not be able to access the headers mentioned above. When supplying a JSONP callback
, these headers will be encoded with the body of the response in the following format.
$ curl 'http://api.meetup.com/dashing-whippets/boards/?key=API_KEY&callback=foo' foo({ "meta": { "status": 200, "X-Meetup-server": "servername", "X-RateLimit-Limit":"limitvalue", "next_link":"http://api.meetup.com/dashing-whippets/boards?callback=foo&key=API_KEY&offset=1", // other headers }, "data": // contents of the normal response )Note that the links from the
Link
header will be render with JSON keys in the form "{rel}_link".
The results
entity contains a list of the items that match the query criteria. Result fields are named values in these items, including simple values like strings and numbers, as well as entities that have values nested inside.
Many API methods support optional result fields, as indicated in their documentation. One or more optional fields may be requested with the fields parameter, with names separated by commas. Since optional fields generally increase the processing time for a request, they should be requested only when needed.
curl 'http://api.meetup.com/2/open_venues?key=yourapikey&zip=10021&fields=taglist'
Result filters reduce the size of API responses. You can suppress result fields by specifying only and/or omit parameters. With only you will retrieve only those fields specified, and with omit you will retrieve all default fields excluding those specified.
For only and omit parameters, the values must be a comma-delimited list of fields. You can specify nested sub-fields using periods, and both filters may be used at once, for example, to include a particular entity and exclude some of its sub-fields.
Search topics for "tech", but only include each topic's id and name (try in API Console):
http://api.meetup.com/topics?key=apikey&search=tech&only=id,name
Query for an event's hosting group information, returning only the group's id and topics, but don't return the urlkey nested in each topic:
http://api.meetup.com/2/events?key=apikey&event_id=someid&only=group.id,group.topics&omit=group.topics.urlkey
Note that this feature is only available for json and xml formats.
Many of the query methods in the API require a member_id
field for filtering. Sometimes you may want that member_id to be the id of the member owning the API key or who authorized an oauth token. To remove the need for an extra query to access that member_id, you may instead use the self
alias in place of the member_id you would have to otherwise query for.
The following is an example of querying the /2/events method for your upcoming Meetup events.
curl 'http://api.meetup.com/2/events/?key=yourapikey&member_id=self'
One notable change in the version 2 API methods is the consistency of event identifiers. In particular, recurring event identifiers. If you post an rsvp for a recurring event using its string identifier in the version 1 API, all future calls relating to that event, will return an the integer version of its identifier. In the version 2 API methods, any reference to a recurring event should retain the string version of its idenfifier. If you post an rsvp for a recurring event in the version 2 API, you should expect the string identifier to remain intact.
This entity, meta
in JSON and head
in XML, supplies information about the response. For query methods, it can be expanded with Geo IP information by specifying a value of geo_ip
in the fields
parameter.
count
is the number of records returnedtotal count
is the total number of records that match your criteriaupdated
is the last time one of the items in the requesttitle, description
some descriptive information about the requestnext
if the total count is more than the count, this URL will request the next set of recordsurl
the URL used to generate this requestmethod
the API method calledgeo_ip
approximate location of the requesting client, if geo_ip
is specified in the fields
parameter
lat
lon
RSS, ATOM and KML topics don't return the meta information provided by the XML & JSON formats.
You can optionally supply request headers which give the API more context for the request.
You can supply the HTTP header X-Meta-Visit
with a value of a valid Meetup group ID. This will notify the API that your application has a context for a user visiting a group. Some API methods that perform an action that creates data like making and RSVP, posting an event comment and checking in do this implicitly. You can provide this request header to provide the same context when querying for data. Organizers on the site often check their member lists sorted by the last time a member visited their group. Using this header will allow this list to be more accurate.
When everything goes well, we'll send a 200 response code along with your data. If there was a problem, you will receive a response with error details formatted in either XML or JSON, depending on which format was requested. Except for JSON callbacks as noted below, error responses will have one of the following HTTP status codes:
The 400 BadRequest response is something of a catch-all: sent if you have incorrect or missing parameters, if you exceed your API limits or you request an unsupported format. The response body will have more detail.
JSON requests that specify a callback parameter are treated differently: the API always responds with an HTTP status of 200, so that a client browser will load the response and handle the callback. When an error occurs its corresponding status line is served in a "status" field of the error response object rather than in the response header.
By default we limit users to 200 requests per hour, and 200 max results for each request. If you exceed this number, the platform will return a 400 error response with limit
as the code
element in the error response body.
The type of authentication used determines how requests are tallied. With OAuth-signed requests, it's the user that authorized the access token. For requests signed by or containing an API Key, the count is distinct to the key owner and the requesting IP address. These methods are designed to scale the rate up with an application's distributed userbase. If your application must perform a large number of non-OAuth requests from a single IP, please get in touch so we can determine an appropriate limit.
API responses to authenticated requests contain information about your current rate limit status in their HTTP headers, as defined here:
X-RateLimit-Limit
The total number of requests you are permitted to make per hourX-RateLimit-Remaining
The number of requests you have remaining before the beginning the next rate limiting intervalX-RateLimit-Reset
The time, in seconds since the unix epoc, when your X-RateLimit-Remaining
count will be reset. Note that elsewhere the API uses milliseconds for its timestamps; for this header it conforms to an evolving rate limit standard.curl -I 'http://api.meetup.com/members/?relation=self&key=yourapikey'
Which should result in something like
HTTP/1.1 200 OK
Date: Wed, 26 Jan 2011 19:02:55 GMT
Server: Apache-Coyote/1.1
X-Meetup-server: x.meetup.com
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 199
X-RateLimit-Reset: 1296072175
Content-Type: text/javascript;charset=ISO-8859-1
Content-Length: 2740
Vary: Accept-Encoding,User-Agent
Connection: close
Meetup Everywhere is built to be simple to use and to share. That means it's not only easier for people everywhere to have Meetups, but it allows us to provide a complete API that is easy for developers, too.
The foundations of this platform are the same as the rest of the API, including response formats and authentication. You can supply an API key, OAuth, or key-signed request for authentication as described in the auth documentation. Much of the interaction, parameter names, response fields, and so on will be familiar to experienced Meetup platform developers, while other parts of the API are a fresh take. Give it a whirl, and as always, don't be shy about voicing your questions and suggestions on the Meetup Developers forum.
To make it easy to develop Meetup Everywhere applications that have little or no local storage, the API supports user defined fields for Containers, Communities, Events, RSVPs and Comments. These field names begin with "udf_" followed by a name you choose, and may be assigned any string value.
User defined fields are assigned and queried just as other fields in the API. Include a parameter beginning with "udf_" in a create or edit POST method to assign it as a field. Field names may be up to 35 characters including the "udf_" prefix. For query methods, specify a UDF parameter with a value to limit the results to those that contain that field with a matching value. The match is case-insensitive and no wildcards are supported.
In result items, these fields are returned only when specified in the fields parameter of the request. Specify "all_udf" to retrieve any fields associated with the entity.
everywhere comments