We have released several enhancements and bug fixes for our TxPUSH services. Note that some of these are breaking changes, but were done to resolve some broken functionality in the existing TxPUSH services. These breaking changes were coordinated with paying partners who are actively using TxPUSH.
JSON Support: TxPUSH now supports JSON notifications, based on the Accept header sent to the service Enable TxPUSH Notifications.
Subscriptions created before this change will always send XML notifications. A subscription created after this change will send JSON notifications if the request to Enable TxPUSH Notifications includes the header Accept: application/json. Otherwise the subscription will send XML content.
If you wish to change the format of an existing subscription, call Disable TxPUSH Notifications to delete the existing subscription, and then call Enable TxPUSH Notifications to re-subscribe using the appropriate Accept header for the desired format.
(This could be a breaking change. If your app was sending and receiving JSON, but was processing TxPUSH notifications as XML, you will find that new subscriptions are sending JSON instead, because of the Accept header that you are sending.)
Corrected Field Names: Inside TxPUSH notifications, two top-level fields were being sent with incorrect field names. The correct field names are:
|class||account or transaction|
|type||created (transaction events only) or currentState or modified or deleted|
(This is a breaking change. In the previous implementation, these fields names were incorrectly reversed.)
Removed institutionTransactionId: The field institutionTransactionId was removed from TxPUSH transaction notifications, to comply with the policy explained in Release Notes - November 2016: "The existence of this field caused confusion about whether client apps needed to perform additional de-duplication after retrieving transactions via the API. Additional de-duplication is not necessary. The Finicity transaction ID is the unique identifier for all transactions in our platform."
(This might be a breaking change, if your app was using this field for some kind of de-duplication after receiving the transaction. Additional de-duplication is not necessary.)
Pending Transactions: TxPUSH supports pending transactions. Notifications now include a status field which may contain the values active, pending or shadow.
A request sent to the service Add Transaction for Testing Account may now include an optional field status with default value active. Sending the value pending will create a pending transaction.
Account Notifications: Account modified notifications are now sent for changes to many different fields in account details, such as paymentDueDate or interestRate.
A friendly reminder of API services that have been deprecated:
The following service will be removed from the API after December 2016:
- Get Subaccounts for Account -- Corporate Card Aggregation services are deprecated and will be discontinued.
The following services will be removed from the API after March 2017:
- Activate Customer Accounts v1 (with Aggregation) -- Use Activate Customer Accounts v2 (without Aggregation) followed by a call to Refresh Institution Login Accounts.
- Activate Customer Accounts v1 (with MFA Answers) -- This call is not necessary if you use Activate Customer Accounts v2 (without Aggregation).
These services will be removed from the API after August 2017:
- Refresh Customer Account -- Use Refresh Institution Login Accounts instead.
- Refresh Customer Account (with MFA Answers) -- Use Refresh Institution Login Accounts (with MFA Answers) instead.
- Modify Customer Account Credentials -- Use Modify Institution Login Credentials instead.
- Get Customer Transactions v2 -- Use Get Customer Transactions v3 instead.
- Get Customer Account Transactions v2 -- Use Get Customer Account Transactions v3 instead.
- Get Customer Transaction v1 -- Use Get Customer Transaction v2 instead.