Skip to main content
This guide explains the workflow of the MDX On Demand method for sending held data, and how to prioritize requests.

​
Workflow

1

A user and member are created

When a user selects an MX product from your UI, your application determines whether the user and member already exist on the MX system. If they don’t, your server issues Create User and Create Member requests to MDX Real Time as needed.
2

If your integration uses MX widgets, the widget URL is requested

After the user and associated member(s) are created, you request a URL from either the Platform API or SSO API to load the widget in the user’s browser, which MX returns. The widget URL is then embedded into your UI and displayed to the user. This is considered a login event.
3

​MX requests accounts, transactions, and holdings

The login event causes MX to initiate an On Demand session with your server to pull the user’s accounts, transactions, and holdings.The session starts with a session call in which MX provides a private credential to your server. You validate the credential and then respond with a session key, which is used only for the duration of the session.After MX receives the session key, we request a list of accounts with a current set of account data, like updated balances and account closures. You respond with the account information.Next, we send a series of requests for transactions or holdings for each account in the account list within a specified date range (typically 15 days). Your response includes all transactions or holdings within that range as they currently exist in your system.After MX has received all requested data, we process and reconcile it in our system.
4

​Data is presented to the user

When using MX widgets, the account, transaction, and holding data is presented to the user automatically. No further action is needed.

​
Prioritizing Requests

Build a prioritization mechanism into your MDX On Demand service to manage the number of simultaneous requests you can process. This is particularly important if the available connections needed to get the data are limited. The number of requests received in a short period of time may vary due to the number of users logging in. The mechanism helps to smooth out the request load so it can be processed successfully. MX can wait for up to 60 seconds for the response to an MDX On Demand request. After 60 seconds, MX terminates the request and cancels the job. A prioritization mechanism can take advantage of this and determine if you can respond to the request in time or if you need to return a 429 Too Many Requests error. This error signals that the issue is related to capacity rather than lack of response. If you’re unable to respond to the volume of requests you’re receiving, change the request priority:
  • Foreground jobs: Prioritize foreground over background jobs. The MDX-Job-type identifies the job type.
  • Transactions: Prioritize requests for transactions over requests for sessions and accounts. It’s more efficient to finish a job that’s currently running than to start a new one.