-
Notifications
You must be signed in to change notification settings - Fork 6
Upgrade to Meetup API v3 Since v2 Deprecated w/o Notice on Aug 20th #20
Comments
Regarding the changes in the response "fields" between v2 and v3 of the events API, here is an example of v2 vs v3 event response for a single event.
|
It just occurred to me that the API key is not required for v2 GET /events. The same is true of the v3 GET of /:urlname/events SOOOOO, removing key= from the Python script actually renders the v2 results, which provides a temporary fix. Given Meetup v2 API is deprecated, and they cut off key authentication, we should still leave this issue open and convert over to v3 API calls. |
Commit 9ecf5cd removes use of Meetup key values, which proved to be unnecessary anyway. |
I actually just committed an update to my local branch, and it seems to have fixed the issue for v3. Now I just need to update format_meetup_events() and then I can issue a pull request for you to have a look. |
Thanks. @bcsnipes I just did a commit so you can git stash your changes, git pull and check what I committed and see if there's anything else that needs to be done. |
@bcsnipes if you have changes to move to v3 events endpoint then that would be the next step, but the commit I just did worked around the v2 auth issue for the reasons mentioned above. |
Kudos to @bcsnipes for getting the start on a v3 Meetup integration. Brett, I think an easy and cleaner way to get the group names is for us to put those values in the organizations API in the "field_events_api_key" field. This way you can just ask for the orgs and the API "key" will be in that data so you don't have to interrogate the URL fields for it. If you have time to update the script to use the value of field_events_api_key then I can update the orgs API with the correct values. |
thanks, @allella, that's a great idea -- I'll work on updating the script. |
@bcsnipes Also, note that if you want to keep your GitHub fork up to date with this copy then one way to do that is similar to how I did a remote tracking branch on your fork. If you see the old notes from our SC Codes map project then there's notes on how to setup an "remote upstream". Basically, it would looks something like
Run The fetch downloads the latest upstream code into a branch within your environment. You won't see anything change, but your local Git then has a copy of the upstream branches at your disposal.
Note that "upstream" could be called anything, but since you forked from this project the word "upstream" is a common vocabulary for it. You'll notice in the pull request comments that I created a remote called "bcsnipes", but I could have called it "brett", or really anything unique besides origin, since "origin" is the default name for your primary remote repo. You can look at .git/config to see where Git stores the relationships between remote names and URLs where they point. |
The field_event_service values are now the "group names" instead of the integers used in the v2 Meetup API. Here's a list of the data, best viewed in Firefox |
Closing this since @bcsnipes #21 and #22, along with removing the authentication, has us running on the v3 Meetup.com API. If we need to request something from v3 that requires authentication then I have an API consumer registered under my account that we could use and/or we can register one under a CFG controlled account.. |
@bcsnipes and @MarkMcDaniels noted the Meetup API is no longer supporting version 2 key authentication.
This majorly broke the ability to pull new/future events (UPDATE: removing key= from the app.py calls to Meetup's v2 API actually worked as a workaround - see below for more).
The script last generated a new file on August 20th and we now see Meetup had an Aug 15th cut-off date. I found a GitHub post from a month earlier, but why they wouldn't email active API key holders with a heads-up is beyond me. Big 🖕 to Meetup for that one.
It would seem the v3 API has been out for some time and this script used a v2 endpoint, perhaps for expedience of querying multiple groups at once.
We started exploring the use of Oauth 2, but it became apparent the pattern is more for creating an app where you need to allow users of your app to authorize certain permissions and then store an token to allow you to act on that user's behalf. This is not our use case, since we're looking to simply query mostly public data from the API from a single scheduled command line script.
In any case, it seems we can still do an API GET query for some endpoints, like the /:urlname/events, just one group at a time.
For instance, here is a list of Code For Greenville events, where (:urlname = Code-for-Greenville).
(if you get a CSRF auth error opening this URL then try a new browser session).
We'll likely also need to reformat the response fields a bit if the field names or values changed between v2 /events and v3 /:urlname/events responses.
Finally, it would seem v3 API uses :urlname and not the integer group_id we have in our organizations API. However, we can rather easily change these API key values in that API.
The text was updated successfully, but these errors were encountered: