> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Request oauth window uri

>  

This endpoint will generate an `oauth_window_uri` for the specified `member`.


## OpenAPI

````yaml openapi/platform-api/v20250224.yaml GET /users/{user_identifier}/members/{member_identifier}/oauth_window_uri
openapi: 3.0.0
info:
  contact:
    name: MX Platform API
    url: https://www.mx.com/products/platform-api
  description: >
    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.


    ## What's Changed?


    Several endpoints, headers, and fields changed in `v20250224`. For more on
    breaking changes, refer to our
    [versioning](/api-reference/platform-api/overview/versioning#v20250224) and
    [migration](/api-reference/platform-api/overview/migration) guides.


    ## Version Header

    Versions are set in the `Accept-Version` header of API requests. Version
    numbers correspond with the date associated with that version.  The example
    below uses the version `v20250224`.


    ```

    -H 'Accept: application/json'

    -H 'Accept-Version: v20250224'

    ```


    ---
  title: MX Platform API
  version: '20250224'
servers:
  - url: https://int-api.mx.com
  - url: https://api.mx.com
security:
  - basicAuth: []
tags:
  - name: authorization
  - name: accounts
    description: >
      The Accounts endpoints represent a user's checking, savings, mortgage,
      401(k), or other types of accounts held by a financial institution.


      An account belongs to a `member`, which represents the user's overall
      relationship with a particular financial institution. A checking account
      may be just one part of a larger relationship that could also include a
      car loan and a savings account.


      Accounts—and the transactions associated with them—are updated every 24
      hours, unless the associated `user` is disabled.


      You can also create manual accounts. Since a manual account has no
      credentials tied to the member, the account will never aggregate or
      include data from a data feed. All manual accounts are automatically
      created under the Manual Institution member.
  - name: ach return
    description: >
      The features documented here are in a beta state, and this documentation
      is considered draft material subject to frequent change.


      Using our Platform API, you can securely submit ACH Returns to reduce your
      ACH return rates and automate your ACH return process.


      You can query the status and outcomes of your submitted ACH returns to
      track progress and access resolution details.
  - name: budgets
    description: >
      Use these endpoints to create and manage budgets for your end users.


      You can create a budget for a specific category or autogenerate a budget
      for several categories based on existing transactions.


      Each budget has a `category_guid`, relating to one of the
      [categories](docs.mx.com/api-reference/platform-api/reference/categories#default-categories-and-subcategories).
  - name: categories
    description: >
      A `transaction` can have its `category` set to one of MX’s default
      categories or a custom category for a specific `user`. 


      See [Default Categories and
      Subcategories](docs.mx.com/api-reference/platform-api/reference/categories#default-categories-and-subcategories)
      for a complete list.
  - name: deprecated
  - name: goals
    description: >
      Use these endpoints to create and manage goals for a `user`. You can also
      reposition goals to adjust their priority levels.


      Every goal has a track type and a meta type.


      The [track
      type](docs.mx.com/api-reference/platform-api/reference/goals/#goal-track-type)
      is the overall classification of the goal (debt, savings, retirement, or
      emergency fund) while the [meta
      type](docs.mx.com/api-reference/platform-api/reference/goals/#goal-meta-type)
      is the specific classification (like college, house, vacation, and so on).
  - name: insights
    description: >
      Use these endpoints to build customizable user experiences in UIs powered
      by our Financial Insights data.


      With Financial Insights, your users will receive personalized insights
      based on their transaction history.


      Want to learn more about the product? See [Financial
      Insights](docs.mx.com/products/experience/insights).


      Looking for a guide to use these endpoints? See [Build Your Own Insights
      UI](docs.mx.com/products/experience/insights/integration-guides/insights-api-guide).
  - name: institutions
    description: >
      Institutions represent a financial institution.


      A single real-world financial institution may have several `institution`
      objects on the MX platform.


      For example, the mortgage division of a financial institution might use a
      separate system than its everyday banking division, which is different
      from its credit card division.


      For more info, see [Institutions
      Overview](docs.mx.com/api-reference/reference/institutions).
  - name: investment holdings
    description: >
      Investment Data Enhancement lets you connect to an end user's financial
      institution and retrieve cleansed and enhanced investment data. By
      combining investment data with retail banking information, you get
      comprehensive insights into customer financial behaviors, risk tolerance,
      and investment strategies.


      You can [read a user's
      holding](docs.mx.com/api-reference/platform-api/reference/read-holding),
      [list all their
      holdings](docs.mx.com/api-reference/platform-api/reference/list-holdings),
      or list their holdings by
      [account](docs.mx.com/api-reference/platform-api/reference/list-holdings-by-account)
      or
      [member](docs.mx.com/api-reference/platform-api/reference/list-holdings-by-member).


      You can also [deactivate a
      user](docs.mx.com/api-reference/platform-api/reference/deactivate-user)
      from the Investment Data Enhancement. This is non-billable.
  - name: managed data
  - name: members
    description: >
      Members represent the connection between an end user and a financial
      institution. This institution may represent your institution or another
      one from which MX is aggregating data.


      For more info, see [Members
      Overview](docs.mx.com/api-reference/reference/members).
  - name: merchants
    description: >
      Merchants are representations of a transaction’s origin. For example, if
      you buy a coffee at Starbucks, the transaction merchant will be
      `Starbucks`.


      Use the `merchant_guid` and a `merchant_location_guidon` any `transaction`
      object to access Merchant endpoints for details like the merchant’s name,
      logo URL, website, street address, and more.
  - name: microdeposits
    description: >
      Microdeposits is an additional verification method that allows you to
      verify account details and navigate the process of using microdeposits and
      the automated clearing house (ACH) system. 


      Make two, small ACH deposits into a consumer's account using the provided
      account and routing number. You can then require that the end user confirm
      the exact amount of each deposit to verify that they own the account and
      meet NACHA’s account verification.


      For more info, including process flows, setting block lists, and more, see
      [Microdeposits](docs.mx.com/products/connectivity/microdeposits).
  - name: monthly cash flow profile
  - name: notifications
    description: >
      You can only use notifications endpoints if you’re using the MX mobile
      application.


      All notifications created through the API will be of notification type
      `API_NOTIFICATION`, channel `PUSH`, and will not be associated to an
      entity. No other channels are supported.


      The read and list endpoints can return any notification associated with
      the `user`, including notifications created by MX for other channels
      besides `PUSH`.
  - name: processor token
  - name: rewards
  - name: spending plan
    description: >
      Use the Spending Plan endpoints to create your own version of our
      [Spending Plan
      Widget](docs.mx.com/products/experience/pfm/legacy-widget-overviews/spending-plan),
      which helps end users track their spending throughout the month.


      To understand key terms and how to best use these endpoints, see [Build
      Your Own Spending Plan
      UI](docs.mx.com/products/experience/pfm/integration-guides/build-your-own-spending-plan-ui).
  - name: statements
    description: >
      With Statements, you can retrieve a user's monthly account statements in
      PDF format. This data can be used for solutions like personal financial
      management or risk analysis.
  - name: taggings
    description: >
      Tags and taggings are two resources in the MX Platform API that, when used
      together, give end users more control over organizing their transactions. 


      A tag is a custom label that can be applied to a transaction.


      After you create a tag, use it for tagging. This means you should actually
      apply the tag to a particular transaction.


      Together, they're a powerful tool for personalization, customization, and
      money management.


      For a guide on creating a tag and then applying it to a specific
      transaction with a tagging, see [Custom Tags and
      Taggings](docs.mx.com/products/experience/pfm/integration-guides/personalization/).
  - name: tags
    description: >
      Tags and taggings are two resources in the MX Platform API that, when used
      together, give end users more control over organizing their transactions. 


      A tag is a custom label that can be applied to a transaction.


      After you create a tag, use it for tagging. This means you should actually
      apply the tag to a particular transaction.


      Together, they're a powerful tool for personalization, customization, and
      money management.


      For a guide on creating a tag and then applying it to a specific
      transaction with a tagging, see [Custom Tags and
      Taggings](docs.mx.com/products/experience/pfm/integration-guides/personalization/).
  - name: transaction rules
    description: >
      Transaction Rules allow users to automatically recategorize or rename all
      similar transactions according to their preferences. This only applies to
      future transactions.


      When recategorizing or renaming a transaction, the user will be asked
      whether they want the new data to apply to the selected transaction or to
      all future transactions. If they choose to apply it to all future
      transactions, it will create a transaction rule which will automatically
      apply the changes going forward.
  - name: transactions
    description: >
      Transactions represent any instance in which money moves into or out of an
      account. This could be a purchase at a business, a payroll deposit, a
      transfer from one account to another, an ATM withdrawal, and so on.


      Transactions are created automatically when a member is successfully
      aggregated.


      Each `transaction` belongs to only one `account`.


      For more info, see [Transactions
      Overview](docs.mx.com/api-reference/reference/transactions).
  - name: users
    description: >
      Users represent an end user using the Platform API through your web or
      mobile app.


      Users are created by MX clients and belong to a specific
      [client](docs.mx.com/products/connectivity/overview/data-architecture/#clients)
      on the platform.
  - name: verifiable credentials
    description: >
      MX provides Verifiable Credential endpoints that comply with web5
      standards. 


      For more info, see [Verifiable Credentials
      Overview](docs.mx.com/api-reference/reference/verifiable-credentials).
  - name: widgets
    description: >
      Use the [Request Widget
      URL](docs.mx.com/api-reference/platform-api/reference/request-widget-url)
      endpoint to generate a URL that loads one of our widgets.


      Many request body parameters only work for some widgets.


      For more info, including widget types, see [Widgets
      Overview](docs.mx.com/api-reference/reference/widgets).
paths:
  /users/{user_identifier}/members/{member_identifier}/oauth_window_uri:
    get:
      tags:
        - widgets
      summary: Request oauth window uri
      description: >-
        This endpoint will generate an `oauth_window_uri` for the specified
        `member`.
      operationId: requestOAuthWindowURI
      parameters:
        - $ref: '#/components/parameters/acceptVersion'
        - $ref: '#/components/parameters/clientRedirectUrl'
        - $ref: '#/components/parameters/enableApp2app'
        - $ref: '#/components/parameters/memberIdentifier'
        - $ref: '#/components/parameters/referralSource'
        - $ref: '#/components/parameters/skipAggregation'
        - $ref: '#/components/parameters/uiMessageWebviewUrlScheme'
        - $ref: '#/components/parameters/userIdentifier'
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/OAuthWindowResponseBody'
          description: OK
components:
  parameters:
    acceptVersion:
      name: Accept-Version
      in: header
      required: true
      schema:
        type: string
        default: v20250224
        example: v20250224
      description: MX Platform API version.
    clientRedirectUrl:
      description: >-
        A URL that MX will redirect to at the end of OAuth with additional query
        parameters. Only available with `referral_source=APP`.
      example: https://{yoursite.com}
      in: query
      name: client_redirect_url
      schema:
        type: string
    enableApp2app:
      description: >-
        This indicates whether OAuth app2app behavior is enabled for
        institutions that support it. Defaults to `true`. When set to `false`,
        any `oauth_window_uri` generated will **not** direct the end user to the
        institution's mobile application. This setting is not persistent. This
        setting currently only affects Chase institutions.
      example: 'false'
      in: query
      name: enable_app2app
      schema:
        type: string
    memberIdentifier:
      description: >-
        Use either the member `id` you defined or the MX-defined member `guid`.
        See [MX-Defined GUIDs vs IDs Defined by
        You](/products/connectivity/overview/held-data/#mx-defined-guids-vs-ids-defined-by-you).
      name: member_identifier
      in: path
      required: true
      schema:
        type: string
    referralSource:
      description: >-
        Must be either `BROWSER` or `APP` depending on the implementation.
        Defaults to `BROWSER`.
      example: APP
      in: query
      name: referral_source
      schema:
        type: string
    skipAggregation:
      description: >-
        Setting this parameter to `true` will prevent the member from
        automatically aggregating after being redirected from the authorization
        page.
      example: false
      in: query
      name: skip_aggregation
      schema:
        type: boolean
    uiMessageWebviewUrlScheme:
      description: >-
        A scheme for routing the user back to the application state they were
        previously in. Only available with `referral_source=APP`.
      in: query
      name: ui_message_webview_url_scheme
      schema:
        type: string
    userIdentifier:
      description: >-
        Use either the user `id` you defined or the MX-defined user `guid`. See
        [MX-Defined GUIDs vs IDs Defined by
        You​](/products/connectivity/overview/held-data/#mx-defined-guids-vs-ids-defined-by-you).
      in: path
      required: true
      name: user_identifier
      schema:
        type: string
  schemas:
    OAuthWindowResponseBody:
      properties:
        member:
          $ref: '#/components/schemas/OAuthWindowResponse'
      type: object
    OAuthWindowResponse:
      properties:
        guid:
          description: The unique identifier for the member. Defined by MX.
          example: MBR-df96fd60-7122-4464-b3c2-ff11d8c74f6f
          nullable: true
          type: string
        oauth_window_uri:
          description: >-
            When connecting a member using OAuth, this field will contain the
            URL to send the user to in order to authenticate, otherwise it will
            be blank.
          example: >-
            https://mxbank.mx.com/oauth/authorize?client_id=b8OikQ4Ep3NuSUrQ13DdvFuwpNx-qqoAsJDVAQCyLkQ&redirect_uri=https%3A%2F%2Fint-app.moneydesktop.com%2Foauth%2Fredirect_from&response_type=code&scope=openid&state=d745bd4ee6f0f9c184757f574bcc2df2
          nullable: true
          type: string
      type: object
  securitySchemes:
    basicAuth:
      scheme: basic
      type: http
      description: >
        The MX Platform API requires basic access authentication using your
        `client_id` and `api_key`. These credentials must be Base64 encoded and
        included in the Authorization header of each API request to ensure
        secure access.


        Here's an example using curl to access `v20250224`. Replace
        `https://int-api.mx.com/endpoint` with the actual API endpoint you wish
        to access and your Base64 encoded `client_id` and `api_key`.


        ```

        curl -L -X POST `https://int-api.mx.com/endpoint' \

        -H 'Content-Type: application/json' \

        -H 'Accept: application/json' \

        -H 'Accept-Version: v20250224'

        -H 'Authorization: Basic BASE_64_ENCODING_OF{client_id:api_key}'

        ```

````