Back to home

PrerequisitesGetting startedReading up on the API docsCreating the API classGetting our profile details using the APISummaryResources and further reading
Authenticating Use For The Swyftx API With Node.js main image

Authenticating Use For The Swyftx API With Node.js

Swyftx is an Australian Cryptocurrency Exchange that allows you to trade Bitcoin, Ethereum, Litecoin, and other cryptocurrencies. According to TrustPilot, they are Australia's most trust exchange. After seeing Swyftx pop up in a recent article on Australia's 25 Best Startups of 2021, I have decided to take more of a dabble into the company do my second plunge into trading.

As an Australian myself that sold most of my crypto back during 2018 (awkward), I missed out on seeing the early days of Swyftx. Since I currently have too much time on my hands and am homeless in Melbourne waiting to be able to move to Brisbane, I have decided that it is the time to reinvigorate my interest in the cryptocurrency industry and trading bots.

This time, I decided that I might share my journey into using the exchange.

This new series over the coming weeks will include the following:

  1. A small dabble into using the API (this post).
  2. Writing an open source TypeScript API for Swyftx (and possibly for other languages if I can be bothered writing the compilers).
  3. A how-to for placing orders using the demo account on the API using a trading bot.

These are just some of the topics I will cover. I genuinely need to get my brain back into the scene, so there may be other accompanying posts on prerequisites that I need to understand and write out the bots.

The post today will be me getting an understanding of setting up a simple API in JavaScript that will be the skeleton for when I write out the TypeScript API in a future post. I want to see how the authentication and demo endpoints work.

Source code can be found here.


  1. Basic familiarity with npm.
  2. Basic familiarity with Node.js.
  3. Have a read on Swyftx - I had to!

Getting started

We will let create-next-app create the project directory hello-swyftx-demo for us:

$ mkdir hello-swyftx-demo $ cd hello-swyftx-demo # Create files to work from $ touch index.js api.js .env # initialise npm project with basics $ npm init -y $ npm install dotenv axios

In our case, I am creating a simple index.js file that will use the Swyftx class that we will create in api.js to make requests to the API.

We will use the dotenv package to load the API key and secret from a .env file.

axios is a JavaScript HTTP client for the browser and Node.js that makes http requests easy peasy. It it my preferred library at the time of writing, but you could replace it with whatever.

At this stage, our project is now ready to start working with.

Reading up on the API docs

The Swyftx docs gives us an overview on the API and the authentication methods.

Reading up on it, we can note that we need to grab an API key from the online platform.

If you head to your dashboard, select Profile > API Keys, you will see a list of your API keys. From here, we can create our own API key.

I wanted to limit the access for this key in certain aspects as it is for a demo, so you can see what access I gave to the key below:

Obtaining an API Key

Obtaining an API Key

Once you have created your key, you can see the details of the key which include the key and access token. Ensure to record both, but it is the access token that we will specifically need.

Place the access token in the .env file under SWYFTX_ACCESS_TOKEN=<your-token-here>. Your .env file should look like the following:


We are now ready to begin writing out some API methods and using them to make requests to the API.

Creating the API class

In the api.js file, add the following:

const axios = require("axios"); class Swyftx { #api; isDemoMode; constructor({ accessToken, isDemoMode } = { isDemoMode: false }) { // Allow a public property for us to know whether or not we are in demo mode this.isDemoMode = isDemoMode; // Base on the constructor, we can set the baseURL to be either the demo or production API. // This defaults to the production API, but we can set it to the demo API if we want. const baseURL = this.isDemoMode ? "" : ""; // Set config defaults when creating the instance this.#api = axios.create({ baseURL, }); // Alter defaults after instance has been created. // These details come from the docs on authentication. // @see this.#api.defaults.headers.common[ "Authorization" ] = `Bearer ${accessToken}`; } /** * Accessor for the `account` endpoints in the API reference. * @see */ get account() { return { profile: { // Path the naming follows reference URL. // For example, this function uses // so we will make the accessor `instance.account.profile.getProfile`. // This is subject to change. getProfile: () => { if (this.isDemoMode) { this.unsupportedEndpoint(); } return this.#api.get("/user").then(({ data }) => data); }, }, }; } /** * Helper for us to raise an error for an unsupported endpoint when using a demo account. * For available methods, check the docs. * @see */ #unsupportedEndpoint() { throw new Error("Endpoint not supported in demo mode"); } } module.exports = { Swyftx, };

This is a first run at what the future TypeScript API might look like.

The design I am going for is to compartmentalize the API into a class that can be used to make requests to the API with access properties on the instance that follow a similar path to the sidebar tree on the API docs, but I may change the design down the track.

The above code itself should outline with comments what I am thinking, but to place it into words below:

  1. We want to be able to create an instance of the API using new Swyftx({ accessToken, isDemoMode }) when the class is imported.
  2. The demo mode only supports certain endpoints, so we will raise errors for certain endpoints if we use them in demo mode with the private helper method #unsupportedEndpoint.
  3. Our constructor takes both the access key and an optional boolean isDemoMode to indicate if we want to use demo mode or not.
  4. The constructor itself creates the axios instance with the authentication and endpoint set up for us to use in other methods with the private instance property #api.

At this stage, our API will only have one method but it is enough for us to create an instance of this API and test both production and demo modes.

Getting our profile details using the API

Within index.js, add the following:

require("dotenv").config(); const { Swyftx } = require("./api"); // Create the Swyftx API instance here const swyftx = new Swyftx({ accessToken: process.env.SWYFTX_ACCESS_TOKEN, isDemoMode: false, }); async function main() { try { // Use the API to get the profile data const profile = await swyftx.account.profile.getProfile(); console.log(profile); } catch (err) { console.log(err); } } main();

Our index.js file is short and contains an asynchronous main function that enables us to use the await keyword on the promises we have added to our API.

At the top of the file, we import our newly written API (although it has only one function implemented) and we create an instance of that API with our access key that is loaded via the .env file.

In our first run, we are also indicating that we wish to run in production mode.

We can run our main function to test the API by running node index.js from our terminal.

$ node index.js { user: { profile: { name: [Object], email: '', phone: '[REDACTED]', address: [Object], accountStatus: [Object], currency: [Object], countryCurrency: [Object], minimumOrderAmount: 1, banxaConsentedAt: null, intercom: [Object], metadata: [Object], userSettings: [Object], entityDetails: [Object], verification: [Object], kyc: [Object] }, ipAddress: '[REDACTED]' } }

As we can see from my logs, we have successfully retrieved the API response!

Awesome, now we can try again in demo mode for an unsupported endpoint by adjusting our isDemoMode property value in index.js from false to true.

# Run our main function $ node index.js Error: Endpoint not supported in demo mode at Swyftx.#unsupportedEndpoint (/path/to/code/projects/hello-swyftx-demo/api.js:83:11) at Object.getProfile (/path/to/code/projects/hello-swyftx-demo/api.js:51:38) at main (/path/to/code/projects/hello-swyftx-demo/index.js:11:50) at Object.<anonymous> (/path/to/code/projects/hello-swyftx-demo/index.js:18:1) at Module._compile (node:internal/modules/cjs/loader:1108:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1137:10) at Module.load (node:internal/modules/cjs/loader:973:32) at Function.Module._load (node:internal/modules/cjs/loader:813:14) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12) at node:internal/main/run_main_module:17:47

Cool! As implemented, we have an error raised when trying to run our API in demo mode.

As far as things go, we have successfully authenticated with the Swyftx API and we can now use it to get our profile details.

I will leave it there as is for our post, but the following posts will look at how we can take what we've done and begin to create a fleshed out Swyftx API written in TypeScript.


Today's post took a simple look at Swyftx and how we can interact with their API by creating our our Node.js wrapper (albeit with one endpoint implemented).

Moving forward in the series, we will flesh this out to be an open source API written in TypeScript and then delve into some trading aspects with the demo account.

Resources and further reading

Photo credit: scottrodgerson

Personal image

Dennis O'Keeffe

  • Melbourne, Australia

Hi, I am a professional Software Engineer. Formerly of Culture Amp, UsabilityHub, Present Company and NightGuru.
I am currently working on, Den Dribbles and LandPad .


Get fresh posts + news direct to your inbox.

No spam. We only send you relevant content.