building your own API

Building your own API is a nightmare: Here’s how to avoid it

| Article by: Antonis KazoulisProfile Image Antonis Kazoulis 7 min

In a recent blog post, we explained APIs and how they work. If you want to get more technical on the API topic, we’ve also explored the open banking API specifications. Today, we’ll take a step back and delve into the world of building an API from scratch. What does that entail, why is it challenging, and why might it be best to avoid it? Let’s get right into it. 

How to build an API

When building an API, there are two things you need to consider: user and developer experience. The API is a means to an end for an end-user, but it’s also a tool and a working vehicle for developers. 

Building the API has as much to do with planning as it does with actual knowledge, skills, and execution. In this blog post, we’ll break down the steps you need to take to build your own API, highlighting the reasons why it’s an overall complicated process. 

Step 1: Identify goals and target audience 

Much like any other project in development, building an API takes some serious planning. This is not the kind of task you just start executing and hope for the best. The process is long and has a lot of implications. The better you plan, the better your chances of success. Here are some questions you need to ask yourself before venturing into development. 

  • Who type of developers could benefit from your API? (their experience level, needs, goals)
  • How can you improve the developer experience?
  • What tools do you need to provide along with your API? (developer programs, SDKs, documentation)
  • What are the functional requirements of your API? (what will the end-user be able to do?) 

The list of questions could be substantially bigger but you get the idea. You need to identify the functional, technical, and usability requirements of the API as best as you can before you get down to the dirty work. 

Step 2: Design the API

Now we move into the designing phase of building your own API. 


Is there anything worse than writing API documentation? Yes. Trying to use an API without documentation. Putting yourself in the user’s shoes is a great way to see why documentation is a necessary evil. Writing documentation used to be a tedious, long and tiring task, but thankfully, there is software to help you generate documentation that outlines essential elements such as requests, responses, and descriptions, independently of what programming language you decide to use.

Is that enough? Not really. Doing the bare minimum is never the goal, and if you wish your documentation, and therefore your API, to be top of the range, you need to take things a step further. Excellent documentation is characterised by detailed examples and tutorials. These resources help developers and users contextualise the API’s use. Excellent API documentation has proven to be the key to unlocking market adoption. 

Stability and consistency

APIs change and evolve over time. How you communicate these changes and different versions is critical to the design of the API. It’s something you need to account for. From URL structure to parameter names, the initial design should be mindful of the changes that will come in the future. 


The testability of your API is directly correlated to deliverability. If you make it simple and easy for people to discover issues, your API will get debugged faster, expediting the market delivery without hidden glitches. 

Testability is an overlooked component of API design. Testable quote takes proficiency, mastery, and experience to write, but the consequences are immeasurable. 


The concept of scalability in API refers to the capacity of the API to manage simultaneous requests without negatively affecting performance. What good is an API if it can’t perform at its best when you need it the most?


You can never anticipate how users will try to utilise your API, but you must be aware that an API needs to be flexible enough to serve different use cases. When creating your own API, you must consider your input and output constraints seriously. You should never assume that people share your technical knowledge or preferences when designing your API interface 


Security is undoubtedly one of the most critical elements of designing your API. The point of contention here is getting the perfect balance between security and ease of use. Users should be able to access examples of authentication and authorizing the API without spending hours or expending resources and effort to do it. Functional security is what modern APIs are all about. 

Ease of adoption  

Always remember that your API is meant to be used by other people. That means you should do everything you can to make it as easy for them to use as possible. Here are some parameters to keep in mind:

  • Simple URL structure 
  • Variety of resources to help adoption, e.g. language-specific libraries 
  • Customer support: FAQs, documentation, chatbot

Step 3: Develop the API

In the title of this blog post, we explicitly use the word nightmare. If what we have described up until this point does not sound like a nightmare, be prepared to lose your sleep from this point forward. 

After you’re done with planning and designing the API, it’s about time you get down to development. The process is long, arduous, and iterative. It requires patience, experience, and skills. The process involves stages identified below:

  • Build all API responses
  • Address errors and anomalies 
  • Develop endpoints, specifying the types of requests they can receive, responses, and errors
  • Create a data pagination system to decrease response times and protect your API against DDoS attacks

Once again, this list could get exhaustively long and detailed. The journey of building APIs is neither simple nor easy. It’s a full-time project with countless moving parts. Even if you manage to survive the development process, more awaits you on the other side. 

Step 4: API testing

Developing an API is one thing. Ensuring it works smoothly and does what it’s supposed to do is an entirely different story. You need to simulate use cases, bring beta users and examine how the technology responds to real-life scenarios. 

Testing the API is another project in itself. The last thing you want is to take the API to market and frustrate users when it fails to deliver. You must take the time to run the API through rigorous testing to discover bugs and errors.

Step 5: Deploy, monitor, and refine

With the testing done, you’re now ready to release your “baby” into the world. Doing that is not the end of it. APIs are living organisms, so they will always need attention, monitoring, and improvement based on user feedback. 

This is not something you build and throw to the market and never look back. You need to be involved post-deployment in tracking things like response time, performance, uptime, etc. 

Challenges of building an API 

Building an API is a multifaceted process that requires a methodic, patient and detailed approach. The challenges of building the API could very well be the same as the steps outlined in the blog post. Everything on that list is challenging, from planning to design to development, deployment, and testing. 

It’s a project that takes more than one person and requires an unbroken commitment to make it work. What if there was a way to turn the nightmare into a dream, avoid the hassle and have someone else worry about this highly technical process? What if you could just get the API and use it without worrying about what goes behind the scenes?

Here’s how to avoid it: Try Nordigen

Nordigen is your one-stop shop for open banking APIs. It provides free access to bank data and premium access to data products for analysis and insights. The powerful Nordigen API technology has the power to let you pull financial data such as the account holder’s name, bank account numbers, transactions, and account balances. It’s all plug-and-play for you, meaning you can forget everything we’ve described prior.

The Nordigen team has taken on the task of unburdening you from building the API and all that it entails and simply deriving its benefits. Pulling data is not the only thing it does, though. 

Nordigen Premium takes open banking API technology to the next level by making sense of raw transaction data through extensive categorisation. Not only does it help you pull data, but it automatically organises it with names and meta information that make it immediately usable. It enriches data with information like transaction type, merchant logo, website, location and more. It eliminates the pain of working with data

Recommended articles