Response Files - MX Documentation

You can optionally have MX generate response files that contain the results of batch processing. This section details their format and content. Response files are named by appending .RESP.pgp to the original file’s name. For example, if you send BankABC.Transactions.2017-11-01.batch001.pgp, the response file will be named BankABC.Transactions.2017-11-01.batch001.RESP.pgp. The .RESP suffix identifies the file as a response file, and the .pgp extension is added due to the file being PGP encrypted.

Requirements

To receive response files, you must provide:

A URL and credentials for your SFTP server, where MX will deliver the files after the batch processing is complete.
A valid username and password. Your SFTP should use username and password authentication.
A public PGP key for MX to use for encrypting the response files.

File Format

Response files are sent in CSV format and encrypted with your provided public PGP key. MX uses standard CSV settings: comma delimiters, newlines for record separators, and quotes for field quoting.

Order of Fields and Addition of New Fields

Don’t rely on the specific order or length of fields in response files, as new fields may be added periodically. Response files include a header row that lists fields and their order. Always use this header row to interpret file contents. If your system requires a specific field length or order, you’ll need to pre-process the CSV file to meet your requirements. This may include:

Re-ordering fields
Eliminating new or unexpected fields
Truncating or expanding fields to a consumable length

Response File Contents

All response files contain a status_code field with an HTTP status for each record from your original request file.

HTTP status codes

200 OK: The upsert action was successful. An existing record was updated.
201 Created: The upsert action was successful. A new record was created.
204 No Content: The delete action was successful. The record was deleted from the MX Platform.
404 Not Found: A dependent record was missing. For example, the user specified in the account record is not present in the MX system.
400 Bad Request: Invalid record. See the message field for details about what was invalid, for example, improper data types, missing required fields, etc.
409 Conflict: The record was not processed. This status can occur when there are duplicate records in the file.

User Response File Fields

Field	Description
`guid`	The unique identifier for the user. Defined by MX.
`id`	The unique partner-defined identifier for the user.
`is_disabled`	This indicates whether the user is disabled.
`message`	The response message from the MX Platform.
`revision`	The revision number of the user record.
`status_code`	The status of the record after batch processing.

Member Response File Fields

Field	Description
`guid`	The unique identifier for the member. Defined by MX.
`id`	The unique partner-defined identifier for the member.
`message`	The response message from the MX Platform.
`revision`	The revision number of the member record.
`status_code`	The status of the record after batch processing.
`user_id`	The unique partner-defined identifier for the user the member belongs to.

Account Response File Fields

Field	Description
`guid`	The unique identifier for the account. Defined by MX.
`id`	The unique partner-defined identifier for the account.
`member_id`	The unique partner-defined identifier for the member the account belongs to.
`message`	The response message from the MX Platform.
`revision`	The revision number of the account record.
`status_code`	The status of the record after batch processing.
`user_id`	The unique partner-defined identifier for the user the account belongs to.

Transaction Response File Fields

Field	Description
`account_id`	The unique partner-defined identifier for the account the transaction belongs to.
`category_guid`	The unique identifier for the category applied to this transaction. Defined by MX.
`description`	The cleansed transaction description.
`guid`	The unique identifier for the transaction. Defined by MX.
`id`	The unique partner-defined identifier for the transaction.
`is_bill_pay`	This indicates whether the transaction is classified as a bill payment.
`is_direct_deposit`	This indicates whether the transaction is classified as a direct deposit.
`is_expense`	This indicates whether the transaction is classified as an expense.
`is_fee`	This indicates whether the transaction is classified as a fee.
`is_income`	This indicates whether the transaction is classified as income.
`is_overdraft_fee`	This indicates whether the transaction is an overdraft fee.
`is_payroll_advance`	This indicates whether the transaction is a payroll advance.
`is_recurring`	This field should be ignored. If this information is required, please reach out to MX to discuss an alternative.
`is_subscription`	If the transaction represents a payment for a subscription service such as Netflix or Audible, this field will be true. Otherwise it will be false.
`merchant_guid`	The unique identifier for the merchant identified in the transaction. Defined by MX.
`merchant_location_guid`	The unique identifier for the merchant location. Defined by MX.
`message`	The response message from the MX Platform.
`latitude`	The latitude of the location where the transaction occurred. The number is a signed decimal (e.g. Rio de Janeiro’s latitude is -22.9027800 and Tokyo’s latitude is 35.689488).
`longitude`	The longitude of the location where the transaction occurred. The number is a signed decimal (e.g. Rio de Janeiro’s longitude is -43.2075000 and Tokyo’s longitude is 139.691706).
`revision`	The revision number of the member record.
`status_code`	The status of the record after batch processing.
`user_id`	The unique partner-defined identifier for the user the transaction belongs to.

​Requirements

​File Format

​Order of Fields and Addition of New Fields

​Response File Contents

​HTTP status codes

​User Response File Fields

​Member Response File Fields

​Account Response File Fields

​Transaction Response File Fields