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: 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.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. 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 . high-level research we did into APIs and the ASX100 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 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 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 the name fields could be combined but that’s nitpicking Verify my email addressLogin The whole process took under 5 minutes. Getting Started 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 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. 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 API Design URL Standard 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/ 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. 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 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. apca Get List of Accounts 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. accountToken Account Token Versioning 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 Going Live to Production I didn’t go down the path of getting production access due to time constraints on my part. Product Strategy 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: 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. 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. 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. 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. and

The Sandbox

Flow

McKinsey’s “Agile Transformation Office” is the Final Nail in the Coffin

What Is Product Management And How It Can Help You Drive Growth

Don't talk to McKinsey, talk to Terem

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Too Long; Didn't Read

Make resilience your competitive advantage

NAB’s API: The Big Reveal

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps