> ## 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.

# Data Recipient Reference

Data Access provides an FDX API to third-party applications (data recipients) for tokenized, secure access to consumer financial data. This includes accounts, transactions, and personal identifying information (PII). The API uses the FDX 4.6 standard for data fetching as well as OpenID Connect (OIDC) for authentication and authorization.

This page gives data recipients much of the information they'll need to use this API.

**Every new data recipient** needs to start with the following tasks, regardless of your particular use case. These will ensure your integration has the fewest possible complications.

* Request access to the API so you can be issued a dynamic client registration key or a list of client IDs and secrets.
* Obtain the full FDX 4.6 API documentation, specifically Parts I and II. This documentation covers information about `customer`, `account` and `transaction` resources. To obtain this information, you'll need to [register on the official FDX website](https://financialdataexchange.org/).
* Read the overview sections that follow, which cover authentication and security, standards and conventions, errors, and more.

## Core Resources

Data recipients can access three core resources through this API: `customers`, `accounts`, and `transactions`.

A `customer` represents the end user whose data you wish to access.

An `account` represents an account with a financial institution such as `CHECKING` or `SAVINGS`. An `account` belongs to the `customer`.

A `transaction` represents a financial transaction either flowing into or out of an account. A `transaction` belongs to an `account`.

## Errors

| Status code             | Definition                                                                                                                                           |
| :---------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- |
| `400 Bad Request`       | Either the scope used was not permitted or the redirect URI used was invalid.                                                                        |
| `401 Unauthorized`      | Either the request was made from an IP address that has not been explicitly allowed or the request came from a client or app that has been disabled. |
| `429 Too Many Requests` | The number of requests has exceeded the rate limit for the data recipient.                                                                           |

## Rate Limiting

Requests are rate limited for all data recipients on all FDX and client-initiated OAuth endpoints. However, this limit isn't fixed and can be adjusted upon request to facilitate changes in application features that require increased volume.

If the rate limit has been reached, the API will return a `429 Too Many Requests` status along with an error message.

```json Example theme={null}
HTTP/1.1 429 Too Many Requests
Content-Type: application/json

{
  "error": "too many requests"
}
```

## Requesting Access

To access the API, data recipients can register on the developer portal if acting as an intermediary, or provide the required information to the data provider via email.

After the request for access has been approved, you will be given a dynamic client registration API key or a list of client IDs and secrets for all submitted applications.

### Required Information

* Company
  * Name
  * Website
  * Address
  * Contact email
  * Contact phone number
* List of all static IPs from which all FDX requests will originate (CIDR supported)
* Estimated aggregated number of requests per hour for all client applications
* List of application(s) requesting access including the following for each:
  * Application name
  * OAuth redirect URI

## Secure Access

All requests to FDX endpoints must include a customer-scoped token issued from the OIDC `/api/v1/oauth/token` endpoint. This token must be passed in the `Authorization` header with the type `Bearer` as shown in the example.

All requests from data recipients must originate from a predetermined IP or CIDR range set during the onboarding process. All requests originating from IPs outside of these will result in a `401 Unauthorized` status from the API, regardless of whether the request contains a valid customer token.

`401 Unauthorized` is also returned if the client and/or application has been given a status of `disabled`.

Endpoint: `GET /api/v1/fdx/customers/current`

<CodeGroup>
  ```shell Request theme={null}
  curl https://base.url.com/api/v1/fdx/customers/current
  -H Authorization: Bearer ${customer_scoped_access_token}
  -H Accept: application/json
  ```

  ```shell Unauthorized theme={null}
  HTTP/1.1 401 Unauthorized
  ```
</CodeGroup>