> ## 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. # Create member > This endpoint allows you to create a new member. Standard members are created with the required parameters credentials and `institution_guid`. When creating a standard member, you'll need to include the correct type of credential required by the financial institution, with values provided by the end user. You can find out which credential type is required with the read institution credentials endpoint.

Once you successfully create a standard member, MX will immediately validate the provided credentials and attempt to aggregate data for accounts and transactions. You can prevent this automatic aggregation by setting the `skip_aggregation` parameter to true. OAuth members can only be created with institutions that support it. OAuth members require no credentials, but do require you to set the is\_oauth parameter to true. OAuth members will be created with a connection status of `PENDING`; a one-time use redirect URI will be provided in the `oauth_window_uri` field of the response. Making a separate request to the `oauth_window_uri` will then take the end user to the registered OAuth application where they can provide credentials and choose what data to share with MX.

After completing the OAuth process, aggregation will automatically begin and the connection status will be updated, unless the `skip_aggregation` parameter was set to true. Partners should not add multiple members to a user if they are connecting to the same institution using the same credentials. This is not supported by many data providers and will result in undefined behavior. This restriction also applies to OAuth members. In addition, it is important to note that the name field is rarely necessary in a member create request. The preferred option is to omit the field and use the default name, i.e. the name of the institution set up by an MX Integration Engineer.

Only in rare circumstances would the name field be supplied in a member create request, and it should not be used unless you have discussed it with a MX Integration Engineer. This endpoint accepts the optional `MX-Skip-Webhook` header and `skip_webhook` parameter. ## OpenAPI ````yaml openapi/nexus/v1.yaml POST /members openapi: 3.0.0 info: contact: name: Nexus API url: https://www.mx.com version: 1.0.0 title: Nexus API description: >- Legacy clients can use Nexus API for all their connectivity needs. If you are a new client refer to our Platform API. Review our [Nexus API Guides](/nexus) for more information. servers: - url: https://int-data.moneydesktop.com/ - url: https://data.moneydesktop.com/ security: - sessionToken: [] tags: - name: accounts - name: beats - name: budgets - name: categories - name: extended transaction history - name: goals - name: holdings - name: identity - name: insights - name: institutions - name: jobs - name: member credentials - name: members - name: merchants - name: microdeposits - name: monthly cash flow profile - name: notifications - name: scheduled payments - name: sessions - name: spending plan - name: taggings - name: tags - name: transaction rules - name: transactions - name: user - name: verification paths: /members: post: tags: - members summary: Create member description: >- This endpoint allows you to create a new member. Standard members are created with the required parameters credentials and `institution_guid`. When creating a standard member, you'll need to include the correct type of credential required by the financial institution, with values provided by the end user. You can find out which credential type is required with the read institution credentials endpoint.



Once you successfully create a standard member, MX will immediately validate the provided credentials and attempt to aggregate data for accounts and transactions. You can prevent this automatic aggregation by setting the `skip_aggregation` parameter to true. OAuth members can only be created with institutions that support it. OAuth members require no credentials, but do require you to set the is_oauth parameter to true. OAuth members will be created with a connection status of `PENDING`; a one-time use redirect URI will be provided in the `oauth_window_uri` field of the response. Making a separate request to the `oauth_window_uri` will then take the end user to the registered OAuth application where they can provide credentials and choose what data to share with MX.



After completing the OAuth process, aggregation will automatically begin and the connection status will be updated, unless the `skip_aggregation` parameter was set to true. Partners should not add multiple members to a user if they are connecting to the same institution using the same credentials. This is not supported by many data providers and will result in undefined behavior. This restriction also applies to OAuth members. In addition, it is important to note that the name field is rarely necessary in a member create request. The preferred option is to omit the field and use the default name, i.e. the name of the institution set up by an MX Integration Engineer.



Only in rare circumstances would the name field be supplied in a member create request, and it should not be used unless you have discussed it with a MX Integration Engineer. This endpoint accepts the optional `MX-Skip-Webhook` header and `skip_webhook` parameter. operationId: createMember requestBody: content: application/vnd.mx.nexus.v1+json: schema: $ref: '#/components/schemas/MemberCreateRequestBody' description: The parameters to create a member. required: true responses: '200': description: OK content: application/vnd.mx.nexus.v1+json: schema: $ref: '#/components/schemas/MemberResponseBody' components: schemas: MemberCreateRequestBody: properties: member: $ref: '#/components/schemas/MemberCreateRequest' type: object MemberResponseBody: properties: member: $ref: '#/components/schemas/MemberResponse' type: object MemberCreateRequest: type: object properties: background_aggregation_is_disabled: example: false type: boolean description: >- This field indicates whether background aggregation is disabled for the member. credentials: type: array description: Required unless `is_oauth` is `true`. items: type: object properties: credential_guid: type: string example: CRD-18cd14ce-2628-5eb6-ae17-b11f89d0b667 description: >- The unique identifier for the institution credential. Obtained from the institution required credentials endpoint. value: type: string example: user-entered-value description: >- The user-provided value for this credential field (e.g., username, password, security answer). client_redirect_url: type: string example: null description: >- The URL to redirect the user to after completing OAuth authentication. connection_status: type: string example: null description: >- Can only be set if the member is under a test institution. Attempting to set this on a member of a non-test institution will result in a `400`. When present, the value must be one of the member connection status strings. If credentials are also set, any value for `connection_status` will be ignored as updating credentials automatically triggers an aggregation job, which will automatically update the connection status. external_guid: type: string example: null description: >- Partner created identifier for the member. It must be unique for all members belonging to all users within the client. institution_guid: type: string example: INS-1572a04c-912b-59bf-5841-332c7dfafaef description: Unique identifier for the institution. Defined by MX. is_oauth: type: boolean example: false description: >- This indicates whether the member uses OAuth to authenticate the member. Defaults to false. authentication. referral_source: type: string example: null description: The source from which the member creation was referred or initiated. metadata: type: string example: Additional information description: Additional information a partner can store on the member. skip_aggregation: type: boolean example: false description: >- When set to true, prevents automatic aggregation from starting after member creation. Defaults to false. skip_webhook: type: boolean example: false description: >- When set to true, prevents webhook notifications from being sent for this member creation. Defaults to false. ui_message_webview_url_scheme: type: string example: null description: >- The URL scheme for displaying UI messages in a webview during the aggregation process. use_cases: type: array description: >- The use case associated with the member. Valid values are `PFM` and/or `MONEY_MOVEMENT`. Only set this if you've met with MX and have opted in to using this field. For more info, see [Member Use Cases](/nexus/member-use-cases). items: type: string enum: - MONEY_MOVEMENT - PFM example: - PFM required: - institution_guid MemberResponse: properties: aggregated_at: example: '2016-10-13T18:07:57.000Z' nullable: true type: string description: >- The date and time the most recent aggregation-type job was started, given in ISO 8601 format with a time component. A job will automatically be started when a member is created or its credentials are updated, unless the `skip_aggregation` parameter is used. Jobs can also be started via manual aggregations, background aggregations, API endpoints, or when opening an MX widget. A job can be a normal aggregation, or a premium job such as identification, verification, fetching statements, or fetching an extended transaction history. If a member is deleted and then re-created with the `skip_aggregation` parameter set to true or if it is re-created within the throttle window (typically three hours), the previous value will be returned. background_aggregation_is_disabled: example: false type: boolean description: >- This field indicates whether background aggregation is disabled for the member. connection_status: example: CONNECTED nullable: true type: string description: >- This field indicates the state of a member's aggregation, provided as a string. external_guid: example: null nullable: true description: >- Partner created identifier for the member. It must be unique for all members belonging to all users within the client. guid: example: MBR-7c6f361b-e582-15b6-60c0-358f12466b4b nullable: true type: string description: Unique identifier for the member. Defined by MX. institution_code: description: The code identifier for the institution. example: chase nullable: true type: string institution_guid: example: INS-1572a04c-912b-59bf-5841-332c7dfafaef description: The unique identifier for the institution. Defined by MX. type: string is_being_aggregated: example: false nullable: true type: boolean description: >- This field will be true if the member is being aggregated at the time of the request. Otherwise, this field will be false. is_managed_by_user: example: false nullable: true type: boolean description: >- If the member is managed by the user, this field will be true. Otherwise, the member is managed by the MX partner, and this field will be false. Members created with Nexus are considered to be managed by the user. This field should be used in place of `is_user_created`. is_oauth: example: false nullable: true type: boolean description: >- This indicates whether the member uses OAuth to authenticate the member. Defaults to false. authentication. is_user_created: example: true description: >- If the member is user created, this field will be true. Otherwise, this field will be false. Members created with Nexus are considered user created. You should use the field `is_managed_by_user` instead of this field as it is being deprecated. type: boolean most_recent_job_guid: description: Unique identifier for the most recent job. Defined by MX. example: JOB-d6bb804b-6d12-44f1-b0ad-403441c03372 type: string metadata: example: '\"credentials_last_refreshed_at\": \"2015-10-15\"' nullable: true type: string description: Additional information a partner can store on the member. name: example: Chase Bank nullable: true type: string description: >- Name of the given member. If omitted in a member create request, the institution name within the MX Platform will be used. successfully_aggregated_at: example: '2016-10-13T17:57:38.000Z' nullable: true type: string description: >- Date and time the account was last successfully aggregated, represented in ISO 8601 format with timestamp (e.g., 2015-04-13T12:01:23-00:00). use_cases: type: array description: >- The use case associated with the member. Valid values are `PFM` and/or `MONEY_MOVEMENT`. Only set this if you've met with MX and have opted in to using this field. For more info, see [Member Use Cases](/nexus/member-use-cases). items: type: string enum: - MONEY_MOVEMENT - PFM example: - PFM user_guid: example: USR-fa7537f3-48aa-a683-a02a-b18940482f54 nullable: true type: string description: >- Unique identifier for the user the member is attached to. Defined by MX. securitySchemes: sessionToken: description: > ### MX Session Token - Request an API token using the read API token endpoint in the MX SSO API. - Exchange an API token for a session token. - A session token is obtained by sending a POST request to /sessions - The session token will be used in each request made for the user. It should be passed in an `MD-SESSION-TOKEN` HTTP header as shown below. - This session token is valid for 30 minutes from the time it was created. The 30 minute expiration counter is refreshed with each call. - If you send a request with an expired session token you'll receive an error code of `4011`. ``` curl -i https://int-data.moneydesktop.com/accounts \ -H 'MD-SESSION-TOKEN: CWforZl1Vn2vC_v6H4rnQRT1DoWpDouJAV-_5TBmiQRAtA8rsOG_BoajTiOSsL0A3bd-bmHXlA-eQzc9ywItKg' \ -H 'Content-Type: application/vnd.mx.nexus.v1+json' \ -H 'Accept: application/vnd.mx.nexus.v1+json' ``` In documentation code examples, replace `` with the session token. type: apiKey name: MD-SESSION-TOKEN in: header ````