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

# Overview

> Data Enhancement Off Platform makes MX's powerful categorization, cleansing, and classification services available to partners.

Data Enhancement Off Platform (formerly known as Sherlock) makes MX's powerful categorization, cleansing, and classification services available to partners. You can group together a set of transactions and call the API. MX will categorize, cleanse, and classify the transactions and return that data for you to use in your own system. Data Enhancement Off Platform also provides supplementary data such as information about merchants and merchant locations.

This product does not persist or store transaction data on the MX platform.

## API Key

```
MD-API-KEY: YOUR_ENVIRONMENT_SPECIFIC_API_KEY
```

## Authentication and Security

Requests must use TLS 1.2 (or higher) with known secure ciphers.

The Data Enhancement uses the same authentication as the MDX, SSO, and Nexus APIs. You must have your IP address whitelisted, include the `MD-API-KEY` header with your respective `api_key`, and have a setting turned on in your client to get access to this service. MX also assigns a client ID; this value must be given as the `client_id` parameter in each request URL.

## Base URL

The URL endpoint in the API has a base URL that will depend on the environment being addressed:

### Production Environment

```
https://deduction.moneydesktop.com/:client_id
```

### Integration Environment (for initial integration testing)

```
https://int-deduction.moneydesktop.com/:client_id
```

## Headers

### Accept Header

All requests require an Accept header to specify the version and the encoding of the desired response body.

```
Accept: application/vnd.mx.deduction.v1+json
```

### Content-Type Header

All requests require a Content-Type header to specify the format of the request body.

```
Content-Type: application/vnd.mx.deduction.v1+json
```

## Errors

The API uses conventional HTTP response codes to indicate success or failure of an API request. In general, codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that resulted from the provided information (e.g., a required parameter was missing, etc.), and codes in the 5xx range indicate an error with MX's servers.

* 200 OK — Everything worked as expected.
* 400 Bad Request — Invalid parameter or body information.
* 401 Unauthorized — No valid API key provided.
* 403 Forbidden — The IP address doesn't match the API key provided or the service is not enabled for the client.
* 404 Not Found — The requested item doesn't exist.
* 500, 502, 503, 504 Server errors — Something went wrong on MX's end.

Sometimes, simply returning the HTTP status code is not enough to indicate what went wrong. To compensate for this, endpoints may respond with a body containing more information about the error.

Error messages are for logging and for informational purposes only and may change from time to time.

```
{
    "error": {
        "code": null,
        "message": "Client not found"
    }
}
```

## Null Values

Fields may return a value of `null` in any number of circumstances, most often when data associated with the field does not exist.

Here are a few examples:

* A `category` object that is already a parent/top-level will have a `null` value in its `parent_guid` field.
* A `transaction` for which no merchant information exists will have a `null` value for its `merchant_guid` and `merchant_location_guid` fields.
* A `merchant` may exist in our system but have no logo available; in that case `default_no_image.png` is returned.

## Transaction IDs

The API is used to categorize and describe transactions based on the information provided in a request. When possible, MX also returns merchant and merchant location information with each transaction. No data is actually created or stored on the MX platform when using Sherlock.

Therefore, MX recommends an `id` be provided with each transaction provided. This `id` can be used to identify the transactions in the response body since they may not be returned in the same order.