NAB’s API: The Big Reveal

We’re working on a more detailed follow up to the high-level research we did into APIs and the ASX100. As part of the follow-up, I’m looking into the APIs offered by ASX100 companies and, for no scientific reason, chose to start with an analysis of NAB’s developer portal.

This post isn’t a strict analysis, rather it’s a sharing of thoughts as I step through NAB’s API with a longer view of gaining a better understanding of API best practices in the wild. 

Overall, NAB’s API is surprisingly good for a bank. Easy to follow, easy to get started.

First Impressions and Portal Home Page 

First impressions of NAB’s API are promising. 

Language is one of being product-led – “register, experiment, go-live” and “open beta”. There is even a hackathon tab.The registration link and documentation links are prominent and easy to navigate. You get the feeling that starting to use it will be straightforward.I get the sense that this is a modern API designed for developers. Actually a little surprised/impressed and excited to play around with it.

Registration

The registration process for NAB had a simple form that only required the most essential fields. It didn’t even ask for an organisation or phone number (quietly impressed). 

The process overall was:

Simple registration form (5 fields) – the name fields could be combined but that’s nitpicking

Verify my email addressLogin

The whole process took under 5 minutes. 

Getting Started

As soon as I logged in I could easily see where to get started. I clicked Getting Started and found my Sandbox API Key. You might wonder why this is worth noting, it’s because many APIs, especially those offered by enterprises and enterprise software providers are bizarrely not this straight forward.

I was able to query NAB locations (i.e. where there is an ATM) within 2 minutes in postman, but I wasn’t easily able to start querying anything that required authentication in postman. When I put my x-nab-key in, I got back “400 Invalid Request” and when I tried the sandbox OAuth flow, I had some errors come back. I could see how to resolve this by writing actual code.

API Documentation

The API endpoint documentation is broken up in an understandable way. It breaks up the API into some high-level, logical areas like Locations, FX and Accounts. It then uses verbs for the titles of the API endpoints themselves (e.g. “Get List of Accounts”) making it easy to see what I can do and what is relevant for me.

Verbs – like “Get” or “Delete” – are generally the actions or tasks that a developer is trying to do. So using language like this matches what they need.

Sample code is provided in multiple languages/technologies: json, curl, java. 

There wasn’t a way to test the endpoints inline. 

API Design

URL Standard

The NAB API follows the RESTful standard closely. Using the HTTP verbs to describe the action being taken – GET – and the URL to describe the resource the action is being applied to – e.g. GET …/accounts/

This makes the APIs easy to follow.

Other APIs sometimes include the verb in the URL itself or don’t follow any standard. The NAB API is a good example of a restful API in the wild.

Variable/Parameters Names

The NAB API’s parameter and variable names were mostly easy to follow and understand. They were usually full names that described themselves. 

There were some exceptions to this like the “apca” attribute on the Get List of Accounts endpoint. It’s unclear what this variable is.

There were some redundant descriptions – e.g. the attribute accountToken has a description of “Account Token” adding no additional information or insight into what this attribute is, what it’s used for or how it’s formed.

Versioning

There is a bit of confusion on the NAB API endpoints with versioning. The version is listed in both the URL and at the end in the query parameters. On the Get List of Accounts endpoint, the endpoint seems to be both version 2 and version 1 at the same time. The variables need different names or the version in the query parameters needs to be removed (what is its purpose?).

Going Live to Production

I didn’t go down the path of getting production access due to time constraints on my part. 

Product Strategy

After walking through the API I stepped back, sipped my coffee and contemplated the API more broadly through the lens of the API as a digital product. Some thoughts:

1. The API appears to be the same API they are using internally for their own digital experience. This is exactly what you want as a company and a third-party developer.
2. The API appears to be useful to startups and more established partners making it more likely to be available in the long run. On the home page, some startups are shown but the functionality appears useful by an enterprise looking to incorporate NAB data into their digital product.