Creating/Updating Events, Ticket Classes, Organizers, and Venues is now available in V3 API (& an early heads-up on upcoming V1 deprecation news)

[Mitch Colleran]

Greetings from Eventbrite's API team! 

We have two very exciting announcements today. First, we have the release of some shiny new endpoints that enable the creation/updating of Events, Ticket Classes, Organizers, and Venues. And second, we have some (early) news to share around our deprecation of API V1 (full notification is going to developers later this week via email). 

New Endpoints Announcement

Today, we're excited to announce new endpoints that allow for the creation and updating of Events, Ticket Classes, Organizers, and Venues. 

• Creating/Updating an Event: http://developer.eventbrite.com/docs/event-details/ 
• Creating/Updating Ticket Classes: http://developer.eventbrite.com/docs/ticket-classes/
• Creating/Updating Venues: http://developer.eventbrite.com/docs/user-venues/
• Creating/Updating Organizers: http://developer.eventbrite.com/docs/user-organizers/

These endpoints have been a long time coming, and we're made possible after an intense back-end re-write to how we create these objects internally (and of course, these are arguably the most important objects within the Eventbrite platform). 

V1 Deprecation plan

Since these new endpoints now get us to parity with the old version of our API, we're ready to take the 'Preview Release' tag off of of API V3 and announce a deprecation plan. We'll be making this announcement directly to active API V1 users via email this week, but we wanted to give a heads-up to this community as soon as we knew. 

We initially launched the new version of the API on February 19th 2014, and we already see a majority of our active Developers leveraging our newest API version. With the release of our first endpoints in February, we covered about ~90% of our developer use-cases -- after the release of these final endpoints, we now cover 100% of our old API use cases. 

For Developers that haven't made the switch from to API V3, we'll be providing support for the legacy API until April 30th, 2015 (on this date, we'll turn off access to the legacy API) -- this is over 6 months from today, and 14 months from the initial launch of the new API. We know that all situations are unique and we work with a wide variety of developers, so if you're concerned about this timeline -- we encourage you to contact us through this form as soon as possible. 

Thanks to everyone who has been a part of the developer community so far, we have some really excited things that we're announcing soon (spoiler alert: Webhooks!) and we're really just getting started. All of the feedback is always appreciated, so keep it coming! 

Cheers,

Eventbrite's Platform Team

[Jon Roma]

Though I have been waiting for the new V3 API, I'm more than a little bit annoyed to read your statement that the V3 API now covers 100% of existing API use cases. That statement is most emphatically incorrect: A critical use case exercised by our organization is the ability to obtain the schedule of repeating events, and is represented by the URL in the legacy V1 API:

https://www.eventbrite.com/json/user_list_events?user_key=xxxxxxxxxx&display=repeat_schedule&app_key=yyyyyyyyyy

We rely heavily on this feature; in 2014 our organization hosts events that, when considering the multiple event occurrences, produce a total of nearly 400 occurrences. As example, we have a weekend event that runs seven times a weekend from May through October and accounts for 126 occurrences. In fact, only one event in our annual calendar is non-recurring.

As everyone who runs multiply-occurring events knows through painful experience, recurring events isn't Eventbrite's strong point; a number of features like being able to set ticket on- and off-sale dates simply don't work with recurring events, and the general experience is awkward. We were told that some improvements in multiply-occurring events was in the works, but the fact that they haven't appears suggests that they are more daunting features than originally perceived.

The inability to use advanced features with our suite of recurring events is annoying, and the delay in more robust handling for multiply-occurring events are both disappointing, but they aren't the end of the world. Losing the ability to query for repeating dates would unquestionably be a showstopper for our organization. It is imperative that a V3 replacement be in place before Eventbrite can claim 100% feature parity with V1.

Other general criticisms:

The statement that the shut-off date of April 30, 2015 represents "14 months from the initial launch of the new API" is utterly meaningless. Customers can not be expected to change gears until the new product is reasonably feature-complete and debugged. As noted above, I see a major feature we use that's lacking from the V3 API.

Furthermore, not every customer has the resources to park themselves on this forum to watch for announcements. Officially, there has never been any notification pushed to customer mailboxes about the V3 API until today's mailing about the V1 API's deprecation. Six months seems like a long time, but I question whether it is sufficient for all small businesses who use Eventbrite – depending on a site's business cycles and the ebb and flow of ticket sales, the date could prove inconvenient.

What about the API client libraries at http://developer.eventbrite.com/doc/libraries/? Will there be replacements, or is that going to be kept secret? I've seen mention in this forum of updated client libraries for V3 (I use Python, FWIW) – but there's nothing on the API documentation page referring to those libraries, or suggesting off-the-shelf components that can be used with V3's paginated, more RESTful API. To anyone who didn't see fit to be an early adopter of V3, help your customers out (and help Eventbrite out by allowing the transition to move forward) by providing more complete information to ease the transition.

The new API is cleaner in many ways than the old one. In particular, the notion of orders is better handled than in the past, and there are other features I like better than V1. But the V3 API's strong suit isn't conciseness – the JSON generated is extremely verbose. I don't see a mechanism by which one can suppress expanding fields that aren't needed for a particular use case. Is this a capability that I have failed to find in the documentation, or is expansion of related fields mandatory behavior?

To sum up, I don't think all the documentation and support for V3 is quite ready, and I have concerns about the six month clock now ticking. But the most significant issue for my organization is the absence of feature parity in terms of retrieving start/end dates for all occurrences of repeating events. Until that feature is available, we are not able to retire our use of the legacy V1 API.

[Mitch Colleran]

Hey Jon! 

First off -- thank you so much for all this feedback! I'll address some of the concerns below, but I want to emphasize an important point for everyone -- we're not going to leave any developers hanging as we work through this transition together. I encourage anyone who is concerned about the timeline or features to contact us (this forum works, but we've also set up a form for this purpose). If anyone feels like we're not meeting your needs or the timeline is too short, then definitely let us know and I promise to work something out that works for you. 

Repeating Events

You're criticism of repeating events is 100% valid. And you're spot-on that repeating events hasn't been one of Eventbrite's strong points, which is why we're excited about some upcoming improvements to the platform (not API specific). Although it hasn't been entirely rolled out (an announcement is pending), we've recently revamped how we handle repeating events across Eventbrite (this is a separate team and separate rollout strategy). After this launch, the new API will display the separate events in a repeating series (so, all events created from today forward will be returned with their repeat schedule as separate events). We have deeper support of repeating events planned for API V3 (beyond the basic inclusion), so stay tuned for announcements (while writing this out, I've come to understand how confusing this concurrent API and repeating events changes are -- I'll follow-up this week with more information in this forum).

Deprecation Window

This is great feedback. We know that there is tons of diversity among our thousands of active V1 developers, and we're committed to coming up with solutions that work for everyone. In the forum and the email, I've included a form to give feedback -- I promise to you, and anyone else who needs it, that I'll work with individual developers when necessary to come up with a plan that suits them. 

Client Libraries

All of the V1 client libraries were developed and supported by the community, we think this is great and something we want to support, but we also received a lot of negative feedback for promoting unofficial libraries that might not be complete/stable/maintained (even when we gave the proper disclaimers). It's a tough balance that we're trying to strike here. Still, thanks for calling this out -- I'll spend some time thinking about how we can play a better role in this. 

Field Expansion / Suppression 

This is great feedback as well, and something we've spent a lot of time thinking about. We're set-up to add this in the future although it's something that we don't currently support, but we're planning on improving this. Stay tuned for updates on this!

Again, all of the feedback is genuinely appreciated. I want to make sure you, and every developer on the Eventbrite API, feels like we're taking care of them -- so if this doesn't address all of your concerns, then feel free to reach out to me directly via private message. 

[Jon Roma]

Hey, Mitch – thanks for the speedy and helpful responses, both to my feedback on this forum and to my colleague Brian via email. I know we'll be engaged in a few conversations off-list before all's said and done, but I wanted to publicly respond to you to thank you, and to offer feedback on your response. I'm glad to hear from someone who cares about the API product and who's responsive to our customer needs.

On Monday, October 20, 2014 9:18:46 PM UTC-5, Mitch Colleran wrote:

Hey Jon! 

First off -- thank you so much for all this feedback! I'll address some of the concerns below, but I want to emphasize an important point for everyone -- we're not going to leave any developers hanging as we work through this transition together. I encourage anyone who is concerned about the timeline or features to contact us (this forum works, but we've also set up a form for this purpose). If anyone feels like we're not meeting your needs or the timeline is too short, then definitely let us know and I promise to work something out that works for you.

This is good to hear. I initially intended to reply using the form Eventbrite set up for responses about the V1 API deprecation, but I subsequently decided that using this group as a forum would be more beneficial. By sharing our concerns with the community, we not only make other customers aware of the issues we see that may affect them, but we also get a dialog going about various use cases for the API – which I think helps both Eventbrite and its community of customers. 

 

Repeating Events

You're criticism of repeating events is 100% valid. And you're spot-on that repeating events hasn't been one of Eventbrite's strong points, which is why we're excited about some upcoming improvements to the platform (not API specific). Although it hasn't been entirely rolled out (an announcement is pending), we've recently revamped how we handle repeating events across Eventbrite (this is a separate team and separate rollout strategy). After this launch, the new API will display the separate events in a repeating series (so, all events created from today forward will be returned with their repeat schedule as separate events). We have deeper support of repeating events planned for API V3 (beyond the basic inclusion), so stay tuned for announcements (while writing this out, I've come to understand how confusing this concurrent API and repeating events changes are -- I'll follow-up this week with more information in this forum).

We're most definitely interested in that information. As mentioned in my original mail, recurring events are our bread and butter – so we have a huge stake in learning how this will work and in advocating for functionality that meets our business needs. I'm very much looking forward to this information. 

 

Deprecation Window

This is great feedback. We know that there is tons of diversity among our thousands of active V1 developers, and we're committed to coming up with solutions that work for everyone. In the forum and the email, I've included a form to give feedback -- I promise to you, and anyone else who needs it, that I'll work with individual developers when necessary to come up with a plan that suits them. 

That's good to know. Though I've already expressed the concern that a six-month window may not be sufficient for some customer use cases, the principal concern for my organization is feature parity. Though I think the deprecation announcement may have been premature, it at least got everyone's attention – and your willingness to engage individual customers means we can work together to get where we need to get. As a developer myself, I understand that old interfaces can't be supported endlessly without expense and that externally-induced code refactors are often expensive too.

Client Libraries

All of the V1 client libraries were developed and supported by the community, we think this is great and something we want to support, but we also received a lot of negative feedback for promoting unofficial libraries that might not be complete/stable/maintained (even when we gave the proper disclaimers). It's a tough balance that we're trying to strike here. Still, thanks for calling this out -- I'll spend some time thinking about how we can play a better role in this.

I've had a chance to think about this, and I'm coming to the point of view that the V3 API is RESTful enough that it doesn't need a client library. Frankly, given that I can make a V3 API request in a half-dozen lines of Python, I don't see that unofficial libraries provide a lot of added value. Still, providing example code snippets might be beneficial for people who aren't seasoned developers and aren't able to intuit some of the nuances. (For those who need a description of REST, see https://www.ibm.com/developerworks/webservices/library/ws-restful/.)

I think it would be a good investment of Eventbrite's time to touch up the API documentation and provide some API examples in common languages Perhaps a prototype client or two. (Take off the "preview mode" verbiage on the API pages too, since V3 is now to be the officially-supported API going forward!)

IMHO, it's probably not worth Eventbrite's time over the long haul to encourage unofficial client libraries. Again, as a developer, I understand that the words "unsupported" don't mean much; if they're offered on your website, you get blamed for their deficiencies and expected to provide support regardless of the disclaimer! 

 

Field Expansion / Suppression 

This is great feedback as well, and something we've spent a lot of time thinking about. We're set-up to add this in the future although it's something that we don't currently support, but we're planning on improving this. Stay tuned for updates on this!

Yes, there is definitely a trade-off involved – on one hand, a lean and clean response object consumes less data and provide zippier response time, but only if the client is not going to immediately turn around and retrieve all those related fields in a later call. This is going to involve latency issues for each request, so in many cases, it still can be less expensive to get all the data in a single API request with pagination. That said, there are some API calls that are extremely verbose, like owned_event_attendees. Over all of our events, this method returns a wealth of information on each attendee, and also repetitively returns information about the related orders, events, venues, etc. That's an immense amount of redundant data to go through, particularly on a high-latency Internet connection! My colleague Brian has also commented to you in his email that, even with V3's paginated responses, it is extremely slow to deliver a page.

Again, all of the feedback is genuinely appreciated. I want to make sure you, and every developer on the Eventbrite API, feels like we're taking care of them -- so if this doesn't address all of your concerns, then feel free to reach out to me directly via private message. 

Thanks again, I know we'll be in touch again here and in private email. 

[Selva Pandian]

How do we copy the existing event through new API? Something similar to event_copy in the V1 API.

[Jon Roma]

Hi, Selva. Your question would probably be best placed in a new topic of its own since it involves a pretty specific "how to" question, rather than being a general comment about the API deprecation. I think reposting your question in a separate topic will also help more people see it and, hopefully, respond to it.

Regards.

[Geoffrey Roberts]

Has there been any movement regarding recurring events support in the Event Brite platform and the V3 API?

[Dana Kock]

Hi Geoffrey,

We have recently rolled out a new version of repeating events across our entire platform.

You can find more info here: http://eventbrite.desk.com/customer/en_us/portal/articles/1669289

[Cris Francisco]

How can we get info on repeating events through the EventBrite V3 API? I'm not able to get at that event schedule information at the moment.

If this is not available now, when will it be available?

[Donald Kerns]

Hi Dana,

  I've watched this discussion since last year. I too am in the process of attempting to integrate Eventbrite recurring events into my customers site. Like many before I've run into the inability to obtain any meaningful information from the old or V3 api regarding recurring events. The display=repeating_schedule in the old api report <repeats>no</repeats>. The new API doesn't even implement the capability nor does it provide the repeating schedule or separate events. 

  While experimenting with the api I have found that if I perform a query for one day Eventbrite will generate an event for that day if it is valid for the repeating schedule set. If you perform a query for a range of dates, whereas an event occurs more than once during that period you get one event and no indication that it repeats on another day. Since I am presenting a monthly calendar to the customer it ridiculous to think that I would perform a query for every day of the month or ask the customer to create individuals events just to present this view. 

  Overall I am shocked that this functionality hasn't received top priority. It is clear from looking at the Eventbrite site that a considerable amount of work has been done to support a user friendly interface for defining recurring schedules. Much of the internal logic to obtain, separate and present this information has already been done. I am unclear why exposing this capability through the API is so difficult.

Does Eventbrite have a strong commitment to provide this functionality and, speaking for many others in this forum, has an ETA been set?

Regards,

Don

[rwva...@gmail.com]

Why isn't more of this info on the developer.eventbrite.com area? I finally found this google group and searching all over the place. And EB tech support could never answer me when I asked if there was some sample PHP code for the new API.

[manish....@gmail.com]

Hi

I want to integrate payment in our app itself using your service how ?

Please help me.

I can able to show Ticket classes and Quantity etc.. in our app itself ,next process is to make the payment i am stuck here.