It's been a while since we've posted an announcement on new Meetup API features, but that doesn't mean we haven't been busy working on tools that will help make it easier to extend the platform.
You may have recently noticed that you can now create an edit events on the official Meetup Android app, a feature that will soon be appearing on our IOS app as well. You may be interested in knowing that the Meetup Android app is entirely powered by the same Meetup API available to all of you. As a result, many of the recent fixes and additions made were related to the event create flows.
Below is a list of new features and upcoming changes.
# POST /batch
There are most certainly times when you want to build a user interface that requires multiple API calls to render. This can be expensive and slow, especially if you are on a mobile network, resulting in a poor member experience. To help ease this burden we've introduced a new endpoint that allows you to make multiple requests within one, POST
http://www.meetup.com/meetup_api/docs/batch/. These requests must be authenticated using OAuth credentials.
You should note the request limiting semantics of these requests. The batch request itself is not rate limited, but the bundled requests themselves are. This was a choice based on the cost of CPU usage that the requests have on our servers. As such, it would be wise not to abuse this endpoint because you can easily put your self into a throttled state.
Also of note, requests included in a batch are processed in parallel and are given equal time to execute. If you have a request that is known to be slow it will likely time out. Timed out requests do not block other requests in a batch from being executed, but timed out requests will be serialized as such in the response. We are currently investigating and improving the performance of slow queries generated by request parameter combinations.
# POST /2/event and /2/event/:id
* Clearer permissions
An emerging pattern has evolved over the last year for exposing what exactly you can do in the API from an authenticated member's perspective. You can find actions available to the authorized member when requesting the "fields" parameter with a value of "self" under the "self.actions" array in the response, we've added a few new ones and better documented existing ones.
* Drafting, announcing, and publishing
You probably have noticed in the past that the public API did not provide much in the way of surfacing your draft events.
Sometimes you may wish to jot down some ideas for an event but don't want to publish them for others to see. To do that, add publish_status set to "draft" in your POST /2/event. To retrieve these drafted events, be sure to set "status" to "draft" when querying GET /2/events. To publish a draft, POST to /2/event/:id with "publish_status" set to "published". You will see a "publish" action in "self.actions" if you can publish an event.
When you create events, members with permission will see an "announce" action in self.actions in the response. You can POST to /2/event/:id with announce parameter set to true to announce an event to your group. You can also optionally supply an "announce_message" parameter containing a custom message to include in the announcement email.
# GET /recommended/venues
# GET /2/open_events prefix searching
We've added a new feature to /2/open_venues (
http://www.meetup.com/meetup_api/docs/2/open_venues/ ) that allows you to do prefix searching by append a "*" character to your text query. For example, text=star* will match "star bucks" and anything else that begins with "star".
# simple html
You may have noticed that the event description on the editor has recently be simplified. This due in part to the benefits had with increasing its maintainability, reducing chances of browser-specific bugs, and to allow for a more consistent experience on the official Meetup apps in the future.
http://help.meetup.com/customer/portal/articles/1218548-how-to-use-the-meetup-event-editor gives you an overview of what simple html means. You can send "is_simplehtml" with the fields parameter to get back a boolean indicating of the description returned is simplehtml or not. Older descriptions are not. You can request simple html in the by appending "simple_html_description" to the "fields" request parameter to get back a simple html representation of the event description, regardless of how it was authored.
# event close times.
We noticed that close_time's, returned in events when the fields parameter includes rsvp_rules did not properly return the currect utc time for timezones out that were not easter standard time. This is now fixed
# sitewide photo syncing
If you are a member of more then 3 groups, you may have noticed that its a really difficult process to update your profile photos if you only want one photo for all your groups. You can now optionally send a "sync_photo" parameter to POST /2/member/self (
http://www.meetup.com/meetup_api/docs/2/member/#edit ) and POST /2/member_photo (
http://www.meetup.com/meetup_api/docs/2/member_photo/#create ) when you upload a photo or send a photo_id. This will effectively sync all of your profile photos across all of your Meetup groups. A very helpful time saver if you want this feature.
# DELETE /2/member_photo
# Rsvping for payment required events
RSVP'ing to paid events hass long been a feature gap for our API users that they can't enable RSVP experiences for members to paid events. We will be soon lifting this restriction.
In order to RSVP to a payment required events you must display this information to a member before sending the "agree_to_refund" parameter when RSVPing to an event in
http://www.meetup.com/meetup_api/docs/2/rsvp/#createparams. The response for these events when successful will contain a new parameter called "payment_redirect" this contains a url you should redirect a member to on
meetup.com where the member can then complete the payment flow for RSVPing to the event. They must do this before they are considered RSVP'ed to the event.
# Moving communication and documentation forward
We moved the API list to google groups so that we could help better manage the communication channels we have with our API users. There are still aspects about its usage that remain point of friction. Reporting bugs, tracking their progress, and tracking feedback on those bugs over time has proven to be difficult on the mailing list. We are investigating using
github.com's issue tracking system for reporting API bugs and using the google groups mailing list as a place for API discussion and general questions.
Using
github.com's issue tracking system would help us ( and you ) keep better track of reported bugs by giving you the ability for you to "track" the bugs you report on a per bug basis. And to look for the existence of a bug in the API before making a duplicate report.
As always, we welcome your feedback.