An update to the recent launch of our universal events submission tool, Auto-Submit, which enables you to submit an event to Eventful and then have it also automatically get submitted to other services, includng Zvents and Upcoming.org.
One of the services we plugged into, Yahoo's Upcoming.org, has decided to (at least temporarily) block events being submitted automatically by the Eventful service. They cite two main reasons:
- The potential for duplicate events and venues being submitted, thus diluting the value of their data.
- Events submitted to Upcoming.org are submitted to an "evdb" user ID, which we created, on the Upcoming service. Upcoming doesn't like this; they would prefer events submitted by the user's real Upcoming user ID.
So let's look at these issues one at a time.
The Deal With Dupes.
Nobody likes duplicate events or venues. It lowers the quality of the database, and it clutters up search results. You see two or ten venues all named nearly the same thing, and you think, why are there so many? Worse, you think, which is the right one? It's messy. So, the goal is to avoid dupes as much as possible.
When we auto-submit an event to Upcoming, we do so using their API. It turned out that the Upcoming API didn't quite provide enough detail to determine if a venue was a duplicate or not. However, we learned this week that they've updated their API and it should be possible to do a fairly good dupe check before actually submitting the event. So we're planning to change our code a bit, using their API functionality, and hopefully the likelihood of dupes will be lessened.
The Deal with user IDs.
Upcoming doesn't like us submitting events into a single user account on their service, particularly an account named "evdb" :-) We did this for a reason. If we'd not done this, then each Eventful user who wanted to auto-submit to Upcoming would have to have TWO things -- 1) an Upcoming user ID and password, and 2) an Upcoming API token. We figured it was very unlikely that a non-technical user would even know what an API token was, let alone have one or know where to get one. The API token requirement seemed to us to essentially kill the idea of event sharing across independent services and systems.
Upcoming has responded to this issue by adding a new set of functionality called "token-based authentication", similar to something available on Flickr's service. We're studying this new functionality now and will post an update to the blog here when we've figured out how to support it on our end.
In the meantime, we're going to disable Upcoming on our end inside the Add Event form, until we hear from Upcoming that they've lifted the ban on their end. Hopefully this will be in a few days.
More details to come.
UPDATE - 12/16/05, 2:46pm
Andy Baio of Upcoming.org AIMed me with some comments on the above post. Here are his comments:
1. We've never blocked the "evdb" user. You can add events now, as you could before. We just won't show your events in public metro pages until the problems you've acknowledged are fixed.
2. You never needed separate API keys or tokens. One API key for all EVDB users is perfectly fine, and you could have passed in username/password before. The token-based auth is just a more secure way of doing this.
3. Duplicate venue checking was available before using two API calls, but we agreed it was easier to have it in a single call and fixed that for you guys.
|
So, events submitted by Eventful users are not "blocked" on Upcoming, per se, just hidden unless you specifically search for them. They don't show up in the Metros event lists, which is one of the more common ways an Upcoming user can see what's going on in a metro area. We hope to have that issue resolved soon.
What's great is that there is a lot of dialog going on between EVDB and Upcoming right now, to resolve the technical issues. Stay tuned, we should have some more news in a few days.
