Skip to main content

Workflow Diagram

A workflow diagram of the OAuth in browsers
1

Create a Member

Now we’ll need to create an OAuth member, which you can do by setting the following: "is_oauth": true.Also, we recommend that you always include a unique id when creating any resource on the Platform API so you can easily sync between your systems and ours.Standard aggregation (of account and transaction data) will start after a successful OAuth connection. This can be disabled with the skip_aggregation parameter.Endpoint: POST /users/{user_guid}/members
WARNINGDo not set "oauth_referral_source": "APP" in browser implementations — this will break OAuth flows. In typical browser environments, you can simply omit that configuration option, or set it to "BROWSER" explicitly.
2

Load the OAuth URI

Now that you have the oauth_window_uri from the last step, load it for the end user.oauth_window_uris are one-time use. Don’t hard code an expected URI into your application.Don’t prepend the https:// protocol to the URI string, as MX includes this.This is where the user will interact with the institution’s OAuth page and determine what data will be shared with MX and, therefore, with you.
3

MX's OAuth Complete Page Loads

This process involves a redirect to an MX webpage whose function is to give the end user information about the end state of the OAuth process, and to deliver important success or failure postMessages.You must capture these postMessages, which will be one of the following:

OAuth Complete Error PostMessage

Triggered when the OAuth process has completed in an error state. The oauthComplete/error message will be sent from the OAuth UI, and is used in API implementations.Error Reasons
JSON

OAuth Complete Success PostMessage

Triggers when the OAuth process has completed in a successful state.
JSON

The process is complete

The OAuth process is now in an end state (either success or error) and the OAuth window can be closed and the user can be redirected where they need to go based on your use case.