About 4 weeks ago, I had the opportunity to take part in a FinTech hackathon in Tel Aviv. Bank Leumi, one of the largest banks in Israel, was organizing the event and Salesforce was sponsoring it. The event was awesome and vibrant. You had plenty of opportunities to meet some clever and creative people and learn about the latest trends in FinTech.
Salesforce was not the only sponsor. There were plenty more, with interesting products to use as part of your hacks. Some companies that were offering their products to use during the event were: Yodlee, import.io, TheThings.io, Built.io, Mashery, OpenBankProject and many more.
There is a clear trend for FinTech startups. Anyone who deals with a bank and some more advanced operations, may understand why this space is ideal for disruption. Although I wouldn’t call myself an expert into FinTech, I enjoyed what I learned during the event, which was a lot. I am even happier as I had the opportunity to get some useful insights about another technology topic that I love, APIs. FinTech is about data, as such, the majority of the products you could work with during the event, were exposing an API.
This is what this post is all about, “APIs and Hackathons”. I want to discuss about things that I saw worked or not and share some personal thoughts about APIs in general. Especially for public APIs exposed to developers and external services.
What’s an API?
Let’s begin with the basics first. The excellent blog from Kin Lane has a great definition of what an API is.
An API allows you to open up data and other digital resources, to public developers, businesses, or even between departments and locations within a company.
I would like to make a clarification here. An API, in concept, is something more generic. We have to be very clear about that. With the term APIs we mean interfaces exposed over the web! It is something that I remember every time when I speak with a game developer who works with Unity.
Back to APIs. We use APIs because of the resources and services that they open up (expose). For this reason an API should add the least possible complexity and overhead.
I also feel that I need to make another small distinction between APIs this time. In my view we have:
- APIs that expose mainly data and
- APIs that provide access to services
An example of accessing a service could be a tax calculation API. Someone may argue that usually we have both scenarios. Let me explain with another example. Twitter’s API exposes data (e.g. you may get a huge list of tweets) and provides access to services (e.g. post a Tweet or authenticate as a user).
The Hackathon experience
Having said that, I can imagine both cases to be of value in a FinTech Hackathon. But I’d argue that data-centric APIs are more common. That was the situation for the Bank Leumi Hackathon too. The majority of the APIs where exposing financial data. You might wonder why this distinction is important.
Learning a new API or a sponsor’s API in a Hackathon takes effort and time. But hackathons are about speed of implementation!
If I know the structure of the data that I’m going to use, it is fast and easy to create a dummy data structure and avoid using these APIs completely. You may create a dummy service too, but I believe we would all agree that it’s more difficult to do so.
We were saying at the beginning of the post, that an API should add the least possible overhead. This is even more profound in the context of a Hackathon. In such a demanding environment, where full integration is not important anyway, it is easy to decide and embed sample data, instead of completely integrating with an API. After the completion of the event, I got the impression that a Hackathon is probably the most demanding environment for someone to promote an API.
A different approach
SalesForce was also offering access to their APIs during the event. The scenario here is different though. First of all, the Salesforce APIs were offering access to specific services and not only data. Try to re-create a dummy CMS, for example. Second, Salesforce is offering a platform that abstracts the majority, if not all, of their APIs. Everything happens through a visual platform. It simplifies the APIs they expose and differentiates the experience. You may still access these APIs directly, but it is not necessary. I believe this was one of the reasons that people used SalesForce a lot compared to the rest APIs and platforms during the event.
But, what can you do as an API provider who wants to promote their API during a Hackathon?
There are common actions which are important for an API in any context.
First of all, good documentation.
It should be not only good, but accessible too. Don’t ask the developer to sign up to get access to the documentation of your API during the hackathon. You are probably wasting her time. That is something that should be true in all cases and most important outside of the Hackathon framework.
Offer easy access.
When you are dealing with sensitive data you need some serious security. But does it matter during Hackathons? In most of the cases, the developer has access to a sandbox and not the real thing. Although it’s something that we may discuss for ages, you may relax security if possible in that case. Yes, it is important, but the developer is after your data not your security. These are things that someone cares when a real integration should occur.
Provide SDKs.
In the case that you don’t want to maintain SDK’s, at least some sample client code. This way the developer can use to connect and start interacting with the API. Creating sample clients in popular computer languages is not that difficult. Even if you have complex security schemes, you may provide the authentication code already implemented. That will definitively make her life much easier.
Offer sample data, explain your data model and communicate its value.
That’s what the developer is after. Not the verbs, not the security tokens. The data and the services you offer. If she doesn’t grab this in just a few minutes she will turn her back to your product during the event.
Offer sandbox environments.
You don’t want them to mess with your real stuff during a hackathon right? What you may do is to offer an Interface customized to the purpose of the Hackathon, on top of your API. In a sense you may do what SalesForce is doing with their UI environment on top of their APIs. It sure doesn’t have to be a UI though. You may create “versions” of the API that make sense for the particular event. Do they need access to every detail of your API to make something out of it during a 24-48h event? Most probably not. Hide the complexity that is part of a more generic product and give only what is of value based on the context of the event.
Concluding
As a conclusion, I’d say that the whole event was fun and valuable. I met some interesting people and learned about new technologies. Most importantly, it made me think and re-evaluate ideas and practices that I was taking for granted till now.
I’d love to hear your opinion and experiences about hackathons as events and APIs. Don’t be shy and drop me a line or two. Especially if you do not agree with the above.
