On Friday afternoon, we had some fun with the Yo API. We wanted to build a program to trigger actions whenever someone sent us a Yo.
From this basic idea, I actually spent a large part of my weekend writing a distributed version, and I had a lot of fun connecting the Yo API with other services (like the Mailjet API to send an email each time someone Yo’ed an account).
While playing around with the API, we also wondered why we were attracted to it in the first place. Having a closer look, we discovered that it has great lessons to teach us!
Yo is still in its infancy but they are moving fast, in a very pragmatic way.
A few weeks ago, you had no way of logging into your account again if you logged out because of a missing password. To get access to the API, you had to wait for a few days. But from the beginning, they knew that their API had a large role to play in their success!
Two weeks ago the only endpoint available was “yoall,” to broadcast a Yo to all the subscribers of an account, without reasonable rate limits.
One week ago, they launched their API dashboard, to create and manage API accounts. They also added some rate limiting (currently one call per minute), to reduce spam.
The API is like the product: simple. For now, all you can do is Yo all your subscribers (“yoall” endpoint) or an individual account (“yo” endpoint) along with getting the subscriber count (“subscribers_count” endpoint).
This simplicity lets people use the API in seconds: a simple call with cURL gives you instant feedback. It should always be that simple!
Providing clean documentation about what your API can do and how to start using it will always be rewarded by developers.
It you think about the Yo API which is still really simple (two endpoints, one parameter: the API token) they still took the time to document it and make this documentation easily accessible from the API dashboard.
Give context to developers
Building simple things doesn’t mean you can’t offer great opportunities, and the guys behind Yo understood this! To succeed, you also need to give context to people to inspire them to create new things.
They organised a hackathon in SF two weeks ago, taking advantage of the momentum their launch has created.
Afterwards, they did a great follow-up blog post featuring all of the great ideas that were developed during the event. Featuring these projects was a great way for people who did not attend to see the opportunities that the product has to offer.
When I read this blog post, it really struck me just how many possibilities there are for building with their API. For example, the BASKETBALLBERRY project featured in the article was a source of great inspiration for me to write this client, one that sends me a Yo if my train is on time according to its schedule.
Always make it easy for developers to show you what they’ve built with your product. That’s always invaluable.
The Yo API is really straightforward, but it opens endless possibilities. The guys behind it did a great job of making developers’ lives really easy by helping them build amazing things with it.
Here’s some ideas to develop
- Yo/Fitbit, Jawbone: Send a Yo at the end of the day if you haven’t reached your goal.
- Yo back timer: a client to send a Yo back to you after X minutes (90 minutes?) when you Yo the account (can be useful for not forgetting to take a break).
- Yo bike sharing system: Yo you back if there’s enough bikes / spots to park in your favorite bike station (for City Bike in NYC, Velib’ in Paris, etc.), based on the train client.
- Yo Twilio: another 3rd party API to integrate, which could send you an SMS (like the Mailjet client for email) each time someone sends you a Yo.
- Yo Slack: post an item on a Slack channel each time someone Yo’ed you.
- Possibilities are endless!
What are your thoughts of integrating Yo in a larger context? Let’s discuss in the comments below.