mxenabled/mx-platform-node

A Node library for the MX Platform API

This project is currently in Beta. Please open up an issue here to report issues using the MX Platform Node.js library.

MX Platform Node.js

The MX Platform API is a powerful, fully-featured API designed to make aggregating and enhancing financial data easy and reliable. It can seamlessly connect your app or website to tens of thousands of financial institutions.

Documentation

Examples for the API endpoints can be found here.

Requirements

The generated Node module can be used in the following environments:

Environment

• Node.js
• Webpack
• Browserify

Language level

• ES5 - you must have a Promises/A+ library installed
• ES6

Module system

• CommonJS
• ES6 module system

Installation

To build and compile the TypeScript sources to JavaScript use:

npm install mx-platform-node

Getting Started

In order to make requests, you will need to sign up for the MX Platform API and get a Client ID and API Key.

Please follow the installation procedure and then run the following code to create your first User:

import { Configuration, MxPlatformApi } from 'mx-platform-node';

const configuration = new Configuration({
  // Configure with your Client ID/API Key from https://dashboard.mx.com
  username: 'Your Client ID',
  password: 'Your API Key',

  // Configure environment. https://int-api.mx.com for development, https://api.mx.com for production
  basePath: 'https://int-api.mx.com',

  baseOptions: {
    headers: {
      Accept: 'application/vnd.mx.api.v1+json'
    }
  }
});

const client = new MxPlatformApi(configuration);

const requestBody = {
  user: {
    metadata: 'Creating a user!'
  }
};

const response = await client.createUser(requestBody);

console.log(response.data);

Development

This project was generated by the OpenAPI Generator. To generate this library, verify you have the latest version of the openapi-generator-cli found here.

Running the following command in this repo's directory will generate this library using the MX Platform API OpenAPI spec with our configuration and templates.

openapi-generator-cli generate \
-i https://raw.githubusercontent.com/mxenabled/openapi/master/openapi/mx_platform_api.yml \
-g typescript-axios \
-c ./openapi/config.yml \
-t ./openapi/templates

Contributing

Please open an issue or submit a pull request.

mx-platform-node's Issues

Feedback: use default baseOptions

Every instantiation of the Configuration object requires the same baseOptions value of { headers: Accept: "application/vnd.mx.api.v1+json" }. For example:

const apiConfig = new Configuration({
  username: process.env.MX_CLIENT_ID,
  password: process.env.MX_API_KEY,
  basePath: process.env.MX_API_URL,
  baseOptions: {
    headers: {
      Accept: "application/vnd.mx.api.v1+json"
    }
  }
})

This library should set this default value.

Feedback: rename configuration properties

The Configuration object should take a clientId and an apiKey instead of a username and password:

// This:
const apiConfig = new Configuration({
  clientId: process.env.MX_CLIENT_ID,
  apiKey: process.env.MX_API_KEY,
})

// Instead of this:
const apiConfig = new Configuration({
  username: process.env.MX_CLIENT_ID,
  password: process.env.MX_API_KEY,
})

Feedback: change interface to configuration basePath property

Rather than having a client pass use the URL to the API (or environment) they want to use, what if we exposed a production key in the Configuration which switch between int and prod:

// This
const apiConfig = new Configuration({
  production: false
})

// Instead of this:
const apiConfig = new Configuration({
  basePath: "https://int-api.mx.com",
})

List institutions does not take page number as input

I can only return the first page of institutions from that function.

All interfaces have optional keys

It seems like all the response interfaces have optional keys (along with some being nullable).

Do these both need to be the case, or is specifying the ones as nullable sufficient? It also seems like these are aggressively nullable, so I'm wondering if all those null scenarios are possible.

It seems a bit cumbersome to have to check for the existence of every key in typescript if it's not nullable.

(I know I can use Required to enforce non-optional, but I'm still wondering if there's something worth looking at here).