Why Startups Need an API

Lucas Brown

When people refer to an API-centric web application, they usually mean that most if not all of the functionality within the app is executed through API calls. That means each system like your databases and your front end application can operate independently but communicate seamlessly. In other words, you can do things like build entirely new interfaces or plug into separate platforms just by using the API calls provided.

In case you’re unfamiliar, API stands for Application Programming Interface. For most SaaS products today, an API most commonly refers to a set of functions built into an application for use by other external applications, but increasingly companies also use their API internally.

At HasOffers, we don’t think of our API as just an extra feature. Our API is our core data layer – core to our business. This allows us to be consistently enhancing the API and regularly sharing those improvements with clients that use it externally.

Why API-Centric Applications Are Cool

For startups looking at building an API, I really recommend approaching your API as your data layer. It should be the first thing you think about as you are building your application.

Designing your data layer with an API in mind forces you to think about all the possible use cases for your data. It allows you to identify the business problems you need to solve, while also getting you in the mindset of thinking about how others may ultimately interface with your data, including potential partners you may find, or even the companies who may be interested in acquiring you.

Building your data-layer with an API has other advantages. You create a unified codebase that you can maintain for internal and external facing applications. There’s no additional work in opening the API, since you simply need a ruleset for who has access to which API methods. Ultimately, you can really increase consistency. Your web interface always returns the same results as other applications making API calls, because you’re addressing the data layer using identical methods.

I learned that we needed to build an API-centric application the hard way. Our original data layer wasn’t written with an API in mind. Our clients using the API had a limited set of features available compared to the universe of features built into our integrated web interface.

On top of all of the flexibility in functionality, using an API as a data layer really equips you to scale. You can even launch separate systems into cloud architectures, testing as you go. Once you have an internal API, you can easily add access controls and authentication processes to securely support external access.

Getting Your API Started

If any of what I’ve said has convinced you to use an API-centric approach to development, you can get started by building your API for internal use first. This really makes sense if your product is brand new and you have no reason to make an external API available to clients. I’d offer advice if you’ve already built your web application without an API. Start building it into your internal process now and eventually it will be complete enough to release for external use.

The first version of our API needed to encapsulate all functionality we already implemented in the application stack as API calls. When we re-wrote our data layer to be an API two years ago, not only did we have to re-write everything from the ground up, we also documented each API call throughout the process. If you have a large code base, as we did, documenting each call can be daunting.

Starting with an API also helps guarantee effective documentation. By starting with an API in mind, you document as you go, allowing you to grow and setting you up to launch a successful external API when you’re ready.

Stay Current

Our team just finished updating our API, making this the third full rewrite in three years. We updated it to PHP 5.3.10, increased data capacity, improved management of larger data sets, made our API requests faster and more efficient. We also updated the framework for the affiliate and advertiser APIs. You can learn more about today’s update in our press release.

I can tell you that this was no cake walk, but the HasOffers engineering team, led by Lee and myself, believe in building the most scalable foundation we can, greatly improving our ability to adapt to the needs of our clients moving forward. After all of this, I can truly say that our API is one of the major differentiating factors between HasOffers and any competition, which also make things easier for our sales and marketing teams. They understand the value of our API, communicate it to clients, and it truly gives us a huge advantage.

Need a new feature? Want to build your own custom front end? Need to integrate with anything under the sun? No problem 🙂

Lucas Brown

Lucas and his twin brother Lee began their first businesses before starting high school in their hometown of Elma, WA. They quickly found this world suited them, launching other successful businesses in college and reporting their first million dollars in revenue as sophomores in their dorms. Developing unique solutions for their own ad network, Lucas had the foresight to white-label their technologies to empower other businesses, which quickly became the birth of TUNE. As Chief Product Officer, Lucas leads agile product teams that strive to quickly meet the needs of an ever growing client base. As a founder, Lucas and his twin brother Lee supported the company in the beginning, growing to profitability by 2010. Lucas’ expertise in complex business models, integrations, implementations, and his constant drive for innovation make him a cornerstone of this Seattle based startup. Lucas graduated from Babson College in Boston, MA.

  • Omar Dalberry

    It’s amazing how many startups fail to even learn how to integrate with API’s let alone develop them. Great article.

    • Lucas Brown

      You couldn’t be more right Omar. I would be one of them several years ago, but the more we grow and scale, I’m not sure how we could have survived without it. 

  • Steve

    True true true… this is a great article, thanks!

  • Phil

    Good point, indeed.  I have built several mash-ups which are completely driven by external API’s, so God only knows why, when starting to code this massive Real Estate project I’m working on, I didn’t think to write the data layer as an API from the get-go.  Luckily, it won’t require a COMPLETE re-write in order to get things functioning as an API, but still, if I had planned this ahead of time I’d be in better shape.  

    Thanks for the reminder. 

  • Anil

    Somewhat confused by the article. Has version 3 been released? I couldn’t find any documentation on it. We’ve seen new bugs in the v2 api in the last couple days – would that be related?

    • Hi Anil, the documentation for v3 is not yet released, but yes, the API you are operating with now is in fact v3. Have we already addressed the bugs you mentioned?  

  • Aaa

    G Проверка коммента

  • I absolutely agree with you Lucas.

  • Applying a local integration mechanism like an “API” to a distributed system like the web will have disastrous consequences over the long term. 
    The REST architectural style has allowed the web to scale to where it is today because it did not apply the concept of APIs. 

  • web design in bangalore

    well written, find your style of writing is very rich. Written in a very good, hope you can continue to try hard, to write better!

  • Angy

    No documentation and no client make api developer angy.