plaid 17.1.0 → 17.2.0

data/lib/plaid/api/plaid_api.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1
@@ -1906,26 +1906,26 @@ module Plaid
 
     # Refresh a user's bank income information
     # `/credit/bank_income/refresh` refreshes the bank income report data for a specific user.
-    # @param credit_bank_income_refresh_request [CreditBankIncomeRefreshRequest] 
+    # @param request_body [Hash<String, Object>] 
     # @param [Hash] opts the optional parameters
     # @return [CreditBankIncomeRefreshResponse]
-    def credit_bank_income_refresh(credit_bank_income_refresh_request, opts = {})
-      data, _status_code, _headers = credit_bank_income_refresh_with_http_info(credit_bank_income_refresh_request, opts)
+    def credit_bank_income_refresh(request_body, opts = {})
+      data, _status_code, _headers = credit_bank_income_refresh_with_http_info(request_body, opts)
       data
     end
 
     # Refresh a user&#39;s bank income information
     # &#x60;/credit/bank_income/refresh&#x60; refreshes the bank income report data for a specific user.
-    # @param credit_bank_income_refresh_request [CreditBankIncomeRefreshRequest] 
+    # @param request_body [Hash<String, Object>] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreditBankIncomeRefreshResponse, Integer, Hash)>] CreditBankIncomeRefreshResponse data, response status code and response headers
-    def credit_bank_income_refresh_with_http_info(credit_bank_income_refresh_request, opts = {})
+    def credit_bank_income_refresh_with_http_info(request_body, opts = {})
       if @api_client.config.debugging
         @api_client.config.logger.debug 'Calling API: PlaidApi.credit_bank_income_refresh ...'
       end
-      # verify the required parameter 'credit_bank_income_refresh_request' is set
-      if @api_client.config.client_side_validation && credit_bank_income_refresh_request.nil?
-        fail ArgumentError, "Missing the required parameter 'credit_bank_income_refresh_request' when calling PlaidApi.credit_bank_income_refresh"
+      # verify the required parameter 'request_body' is set
+      if @api_client.config.client_side_validation && request_body.nil?
+        fail ArgumentError, "Missing the required parameter 'request_body' when calling PlaidApi.credit_bank_income_refresh"
       end
       # resource path
       local_var_path = '/credit/bank_income/refresh'
@@ -1944,7 +1944,7 @@ module Plaid
       form_params = opts[:form_params] || {}
 
       # http body (model)
-      post_body = opts[:debug_body] || @api_client.object_to_http_body(credit_bank_income_refresh_request)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(request_body)
 
       # return_type
       return_type = opts[:debug_return_type] || 'CreditBankIncomeRefreshResponse'
@@ -2229,8 +2229,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Create a `relay_token` to share an Asset Report with a partner client
-    # Plaid can share an Asset Report directly with a participating third party on your behalf. The shared Asset Report is the exact same Asset Report originally created in `/asset_report/create`.  To grant access to an Asset Report to a third party, use the `/credit/relay/create` endpoint to create a `relay_token` and then pass that token to the third party who needs access. Each third party has its own `secondary_client_id`, for example `ce5bd328dcd34123456`. You'll need to create a separate `relay_token` for each third party to whom you want to grant access to the Report.
+    # Create a relay token to share an Asset Report with a partner client (beta)
+    # Plaid can share an Asset Report directly with a participating third party on your behalf. The shared Asset Report is the exact same Asset Report originally created in `/asset_report/create`.  To grant a third party access to an Asset Report, use the `/credit/relay/create` endpoint to create a `relay_token` and then pass that token to your third party. Each third party has its own `secondary_client_id`; for example, `ce5bd328dcd34123456`. You'll need to create a separate `relay_token` for each third party that needs access to the report on your behalf.
     # @param credit_relay_create_request [CreditRelayCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CreditRelayCreateResponse]
@@ -2239,8 +2239,8 @@ module Plaid
       data
     end
 
-    # Create a &#x60;relay_token&#x60; to share an Asset Report with a partner client
-    # Plaid can share an Asset Report directly with a participating third party on your behalf. The shared Asset Report is the exact same Asset Report originally created in &#x60;/asset_report/create&#x60;.  To grant access to an Asset Report to a third party, use the &#x60;/credit/relay/create&#x60; endpoint to create a &#x60;relay_token&#x60; and then pass that token to the third party who needs access. Each third party has its own &#x60;secondary_client_id&#x60;, for example &#x60;ce5bd328dcd34123456&#x60;. You&#39;ll need to create a separate &#x60;relay_token&#x60; for each third party to whom you want to grant access to the Report.
+    # Create a relay token to share an Asset Report with a partner client (beta)
+    # Plaid can share an Asset Report directly with a participating third party on your behalf. The shared Asset Report is the exact same Asset Report originally created in &#x60;/asset_report/create&#x60;.  To grant a third party access to an Asset Report, use the &#x60;/credit/relay/create&#x60; endpoint to create a &#x60;relay_token&#x60; and then pass that token to your third party. Each third party has its own &#x60;secondary_client_id&#x60;; for example, &#x60;ce5bd328dcd34123456&#x60;. You&#39;ll need to create a separate &#x60;relay_token&#x60; for each third party that needs access to the report on your behalf.
     # @param credit_relay_create_request [CreditRelayCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreditRelayCreateResponse, Integer, Hash)>] CreditRelayCreateResponse data, response status code and response headers
@@ -2294,8 +2294,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Retrieve the reports associated with a Relay token that was shared with you
-    # `/credit/relay/get` allows third parties to get a report that was shared with them, using an `relay_token` that was created by the report owner.
+    # Retrieve the reports associated with a relay token that was shared with you (beta)
+    # `/credit/relay/get` allows third parties to receive a report that was shared with them, using a `relay_token` that was created by the report owner.
     # @param credit_relay_get_request [CreditRelayGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [AssetReportGetResponse]
@@ -2304,8 +2304,8 @@ module Plaid
       data
     end
 
-    # Retrieve the reports associated with a Relay token that was shared with you
-    # &#x60;/credit/relay/get&#x60; allows third parties to get a report that was shared with them, using an &#x60;relay_token&#x60; that was created by the report owner.
+    # Retrieve the reports associated with a relay token that was shared with you (beta)
+    # &#x60;/credit/relay/get&#x60; allows third parties to receive a report that was shared with them, using a &#x60;relay_token&#x60; that was created by the report owner.
     # @param credit_relay_get_request [CreditRelayGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(AssetReportGetResponse, Integer, Hash)>] AssetReportGetResponse data, response status code and response headers
@@ -2359,8 +2359,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Refresh a report of a Relay Token
-    # The `/credit/relay/refresh` endpoint allows third parties to refresh an report that was relayed to them, using a `relay_token` that was created by the report owner. A new report will be created based on the old one, but with the most recent data available.
+    # Refresh a report of a relay token (beta)
+    # The `/credit/relay/refresh` endpoint allows third parties to refresh a report that was relayed to them, using a `relay_token` that was created by the report owner. A new report will be created with the original report parameters, but with the most recent data available based on the `days_requested` value of the original report.
     # @param credit_relay_refresh_request [CreditRelayRefreshRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CreditRelayRefreshResponse]
@@ -2369,8 +2369,8 @@ module Plaid
       data
     end
 
-    # Refresh a report of a Relay Token
-    # The &#x60;/credit/relay/refresh&#x60; endpoint allows third parties to refresh an report that was relayed to them, using a &#x60;relay_token&#x60; that was created by the report owner. A new report will be created based on the old one, but with the most recent data available.
+    # Refresh a report of a relay token (beta)
+    # The &#x60;/credit/relay/refresh&#x60; endpoint allows third parties to refresh a report that was relayed to them, using a &#x60;relay_token&#x60; that was created by the report owner. A new report will be created with the original report parameters, but with the most recent data available based on the &#x60;days_requested&#x60; value of the original report.
     # @param credit_relay_refresh_request [CreditRelayRefreshRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreditRelayRefreshResponse, Integer, Hash)>] CreditRelayRefreshResponse data, response status code and response headers
@@ -2424,8 +2424,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Remove Credit Relay Token
-    # The `/credit/relay/remove` endpoint allows you to invalidate a `relay_token`, meaning the third party holding the token will no longer be able to use it to access the reports to which the `relay_token` gives access to. The report, items associated with it, and other Relay tokens that provide access to the same report are not affected and will remain accessible after removing the given `relay_token.
+    # Remove relay token (beta)
+    # The `/credit/relay/remove` endpoint allows you to invalidate a `relay_token`. The third party holding the token will no longer be able to access or refresh the reports which the `relay_token` gives access to. The original report, associated Items, and other relay tokens that provide access to the same report are not affected and will remain accessible after removing the given `relay_token`.
     # @param credit_relay_remove_request [CreditRelayRemoveRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CreditRelayRemoveResponse]
@@ -2434,8 +2434,8 @@ module Plaid
       data
     end
 
-    # Remove Credit Relay Token
-    # The &#x60;/credit/relay/remove&#x60; endpoint allows you to invalidate a &#x60;relay_token&#x60;, meaning the third party holding the token will no longer be able to use it to access the reports to which the &#x60;relay_token&#x60; gives access to. The report, items associated with it, and other Relay tokens that provide access to the same report are not affected and will remain accessible after removing the given &#x60;relay_token.
+    # Remove relay token (beta)
+    # The &#x60;/credit/relay/remove&#x60; endpoint allows you to invalidate a &#x60;relay_token&#x60;. The third party holding the token will no longer be able to access or refresh the reports which the &#x60;relay_token&#x60; gives access to. The original report, associated Items, and other relay tokens that provide access to the same report are not affected and will remain accessible after removing the given &#x60;relay_token&#x60;.
     # @param credit_relay_remove_request [CreditRelayRemoveRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreditRelayRemoveResponse, Integer, Hash)>] CreditRelayRemoveResponse data, response status code and response headers
@@ -5740,7 +5740,7 @@ module Plaid
     end
 
     # Create a payment
-    # After creating a payment recipient, you can use the `/payment_initiation/payment/create` endpoint to create a payment to that recipient.  Payments can be one-time or standing order (recurring) and can be denominated in either EUR or GBP.  If making domestic GBP-denominated payments, your recipient must have been created with BACS numbers. In general, EUR-denominated payments will be sent via SEPA Credit Transfer and GBP-denominated payments will be sent via the Faster Payments network, but the payment network used will be determined by the institution. Payments sent via Faster Payments will typically arrive immediately, while payments sent via SEPA Credit Transfer will typically arrive in one business day.  Standing orders (recurring payments) must be denominated in GBP and can only be sent to recipients in the UK. Once created, standing order payments cannot be modified or canceled via the API. An end user can cancel or modify a standing order directly on their banking application or website, or by contacting the bank. Standing orders will follow the payment rules of the underlying rails (Faster Payments in UK). Payments can be sent Monday to Friday, excluding bank holidays. If the pre-arranged date falls on a weekend or bank holiday, the payment is made on the next working day. It is not possible to guarantee the exact time the payment will reach the recipient’s account, although at least 90% of standing order payments are sent by 6am.  In the Development environment, payments must be below 5 GBP / EUR. For details on any payment limits in Production, contact your Plaid Account Manager.
+    # After creating a payment recipient, you can use the `/payment_initiation/payment/create` endpoint to create a payment to that recipient.  Payments can be one-time or standing order (recurring) and can be denominated in either EUR, GBP or other chosen [currency](https://plaid.com/docs/api/products/payment-initiation/#payment_initiation-payment-create-request-amount-currency).  If making domestic GBP-denominated payments, your recipient must have been created with BACS numbers. In general, EUR-denominated payments will be sent via SEPA Credit Transfer, GBP-denominated payments will be sent via the Faster Payments network and for non-Eurozone markets typically via the local payment scheme, but the payment network used will be determined by the institution. Payments sent via Faster Payments will typically arrive immediately, while payments sent via SEPA Credit Transfer or other local payment schemes will typically arrive in one business day.  Standing orders (recurring payments) must be denominated in GBP and can only be sent to recipients in the UK. Once created, standing order payments cannot be modified or canceled via the API. An end user can cancel or modify a standing order directly on their banking application or website, or by contacting the bank. Standing orders will follow the payment rules of the underlying rails (Faster Payments in UK). Payments can be sent Monday to Friday, excluding bank holidays. If the pre-arranged date falls on a weekend or bank holiday, the payment is made on the next working day. It is not possible to guarantee the exact time the payment will reach the recipient’s account, although at least 90% of standing order payments are sent by 6am.  In the Development environment, payments must be below 5 GBP or other chosen [currency](https://plaid.com/docs/api/products/payment-initiation/#payment_initiation-payment-create-request-amount-currency). For details on any payment limits in Production, contact your Plaid Account Manager.
     # @param payment_initiation_payment_create_request [PaymentInitiationPaymentCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [PaymentInitiationPaymentCreateResponse]
@@ -5750,7 +5750,7 @@ module Plaid
     end
 
     # Create a payment
-    # After creating a payment recipient, you can use the &#x60;/payment_initiation/payment/create&#x60; endpoint to create a payment to that recipient.  Payments can be one-time or standing order (recurring) and can be denominated in either EUR or GBP.  If making domestic GBP-denominated payments, your recipient must have been created with BACS numbers. In general, EUR-denominated payments will be sent via SEPA Credit Transfer and GBP-denominated payments will be sent via the Faster Payments network, but the payment network used will be determined by the institution. Payments sent via Faster Payments will typically arrive immediately, while payments sent via SEPA Credit Transfer will typically arrive in one business day.  Standing orders (recurring payments) must be denominated in GBP and can only be sent to recipients in the UK. Once created, standing order payments cannot be modified or canceled via the API. An end user can cancel or modify a standing order directly on their banking application or website, or by contacting the bank. Standing orders will follow the payment rules of the underlying rails (Faster Payments in UK). Payments can be sent Monday to Friday, excluding bank holidays. If the pre-arranged date falls on a weekend or bank holiday, the payment is made on the next working day. It is not possible to guarantee the exact time the payment will reach the recipient’s account, although at least 90% of standing order payments are sent by 6am.  In the Development environment, payments must be below 5 GBP / EUR. For details on any payment limits in Production, contact your Plaid Account Manager.
+    # After creating a payment recipient, you can use the &#x60;/payment_initiation/payment/create&#x60; endpoint to create a payment to that recipient.  Payments can be one-time or standing order (recurring) and can be denominated in either EUR, GBP or other chosen [currency](https://plaid.com/docs/api/products/payment-initiation/#payment_initiation-payment-create-request-amount-currency).  If making domestic GBP-denominated payments, your recipient must have been created with BACS numbers. In general, EUR-denominated payments will be sent via SEPA Credit Transfer, GBP-denominated payments will be sent via the Faster Payments network and for non-Eurozone markets typically via the local payment scheme, but the payment network used will be determined by the institution. Payments sent via Faster Payments will typically arrive immediately, while payments sent via SEPA Credit Transfer or other local payment schemes will typically arrive in one business day.  Standing orders (recurring payments) must be denominated in GBP and can only be sent to recipients in the UK. Once created, standing order payments cannot be modified or canceled via the API. An end user can cancel or modify a standing order directly on their banking application or website, or by contacting the bank. Standing orders will follow the payment rules of the underlying rails (Faster Payments in UK). Payments can be sent Monday to Friday, excluding bank holidays. If the pre-arranged date falls on a weekend or bank holiday, the payment is made on the next working day. It is not possible to guarantee the exact time the payment will reach the recipient’s account, although at least 90% of standing order payments are sent by 6am.  In the Development environment, payments must be below 5 GBP or other chosen [currency](https://plaid.com/docs/api/products/payment-initiation/#payment_initiation-payment-create-request-amount-currency). For details on any payment limits in Production, contact your Plaid Account Manager.
     # @param payment_initiation_payment_create_request [PaymentInitiationPaymentCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(PaymentInitiationPaymentCreateResponse, Integer, Hash)>] PaymentInitiationPaymentCreateResponse data, response status code and response headers
@@ -5935,7 +5935,7 @@ module Plaid
     end
 
     # Reverse an existing payment
-    # Reverse a previously settled payment from a Plaid virtual account.  The original payment must be in a settled state to be refunded and only full payment refunds are currently supported. To power partial refunds, use `/wallet/transaction/execute`, where you can specify the exact amount for a payout to an end user.  A payment can only be reversed once and will be refunded back to the same source account that initiated the payment. The original payment must have been initiated to a Plaid virtual account. The refund will be initiated from the same virtual account that the payment was paid into. 
+    # Reverse a settled payment from a Plaid virtual account.  The original payment must be in a settled state to be refunded. To refund partially, specify the amount as part of the request. If the amount is not specified, the refund amount will be equal to all of the remaining payment amount that has not been refunded yet. If the remaining amount is less than one unit of currency (e.g. 1 GBP or 1 EUR), the refund will fail.  The refund will go back to the source account that initiated the payment. The original payment must have been initiated to a Plaid virtual account so that this account can be used to initiate the refund. 
     # @param payment_initiation_payment_reverse_request [PaymentInitiationPaymentReverseRequest] 
     # @param [Hash] opts the optional parameters
     # @return [PaymentInitiationPaymentReverseResponse]
@@ -5945,7 +5945,7 @@ module Plaid
     end
 
     # Reverse an existing payment
-    # Reverse a previously settled payment from a Plaid virtual account.  The original payment must be in a settled state to be refunded and only full payment refunds are currently supported. To power partial refunds, use &#x60;/wallet/transaction/execute&#x60;, where you can specify the exact amount for a payout to an end user.  A payment can only be reversed once and will be refunded back to the same source account that initiated the payment. The original payment must have been initiated to a Plaid virtual account. The refund will be initiated from the same virtual account that the payment was paid into. 
+    # Reverse a settled payment from a Plaid virtual account.  The original payment must be in a settled state to be refunded. To refund partially, specify the amount as part of the request. If the amount is not specified, the refund amount will be equal to all of the remaining payment amount that has not been refunded yet. If the remaining amount is less than one unit of currency (e.g. 1 GBP or 1 EUR), the refund will fail.  The refund will go back to the source account that initiated the payment. The original payment must have been initiated to a Plaid virtual account so that this account can be used to initiate the refund. 
     # @param payment_initiation_payment_reverse_request [PaymentInitiationPaymentReverseRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(PaymentInitiationPaymentReverseResponse, Integer, Hash)>] PaymentInitiationPaymentReverseResponse data, response status code and response headers
@@ -6000,7 +6000,7 @@ module Plaid
     end
 
     # Create payment recipient
-    # Create a payment recipient for payment initiation.  The recipient must be in Europe, within a country that is a member of the Single Euro Payment Area (SEPA).  For a standing order (recurring) payment, the recipient must be in the UK.  It is recommended to use `bacs` in the UK and `iban` in EU.  The endpoint is idempotent: if a developer has already made a request with the same payment details, Plaid will return the same `recipient_id`. 
+    # Create a payment recipient for payment initiation.  The recipient must be in Europe, within a country that is a member of the Single Euro Payment Area (SEPA) or a non-Eurozone country [supported](https://plaid.com/global) by Plaid. For a standing order (recurring) payment, the recipient must be in the UK.  It is recommended to use `bacs` in the UK and `iban` in EU.  The endpoint is idempotent: if a developer has already made a request with the same payment details, Plaid will return the same `recipient_id`. 
     # @param payment_initiation_recipient_create_request [PaymentInitiationRecipientCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [PaymentInitiationRecipientCreateResponse]
@@ -6010,7 +6010,7 @@ module Plaid
     end
 
     # Create payment recipient
-    # Create a payment recipient for payment initiation.  The recipient must be in Europe, within a country that is a member of the Single Euro Payment Area (SEPA).  For a standing order (recurring) payment, the recipient must be in the UK.  It is recommended to use &#x60;bacs&#x60; in the UK and &#x60;iban&#x60; in EU.  The endpoint is idempotent: if a developer has already made a request with the same payment details, Plaid will return the same &#x60;recipient_id&#x60;. 
+    # Create a payment recipient for payment initiation.  The recipient must be in Europe, within a country that is a member of the Single Euro Payment Area (SEPA) or a non-Eurozone country [supported](https://plaid.com/global) by Plaid. For a standing order (recurring) payment, the recipient must be in the UK.  It is recommended to use &#x60;bacs&#x60; in the UK and &#x60;iban&#x60; in EU.  The endpoint is idempotent: if a developer has already made a request with the same payment details, Plaid will return the same &#x60;recipient_id&#x60;. 
     # @param payment_initiation_recipient_create_request [PaymentInitiationRecipientCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(PaymentInitiationRecipientCreateResponse, Integer, Hash)>] PaymentInitiationRecipientCreateResponse data, response status code and response headers
@@ -7755,7 +7755,7 @@ module Plaid
     end
 
     # Advance a test clock
-    # Use the `/sandbox/transfer/test_clock/advance` endpoint to advance a `test_clock` in the Sandbox environment.   A test clock object represents an independent timeline and has a `frozen_timestamp` field indicating the current timestamp of the timeline. A test clock can be advanced by incrementing `frozen_timestamp`, but may never go back to a lower `frozen_timestamp`.  If a test clock is advanced from T1 to T2, we will simulate the changes that ought to occur during the period of (T1, T2].  For instance, a client creates a weekly recurring transfer with a test clock set at t. When the client advances the test clock by setting `frozen_timestamp` = t + 15 days, 2 new originations should be created, along with the webhook events. The timestamps of the objects and webhook events created/updated in step 2 should also fall in (T1, T2] time range.  The advancement of the test clock from its current `frozen_timestamp` should be limited such that there are no more than 20 originations resulted from the advance operation on each `recurring_transfer` associated with this `test_clock`.  For instance, if the recurring transfer associated with this test clock originates once every 4 weeks, you can advance the `frozen_timestamp` up to 80 weeks on each advance call.
+    # Use the `/sandbox/transfer/test_clock/advance` endpoint to advance a `test_clock` in the Sandbox environment.  A test clock object represents an independent timeline and has a `virtual_time` field indicating the current timestamp of the timeline. A test clock can be advanced by incrementing `virtual_time`, but may never go back to a lower `virtual_time`.  If a test clock is advanced, we will simulate the changes that ought to occur during the time that elapsed. For instance, a client creates a weekly recurring transfer with a test clock set at t. When the client advances the test clock by setting `virtual_time` = t + 15 days, 2 new originations should be created, along with the webhook events.  The advancement of the test clock from its current `virtual_time` should be limited such that there are no more than 20 originations resulting from the advance operation on each `recurring_transfer` associated with the `test_clock`. For instance, if the recurring transfer associated with this test clock originates once every 4 weeks, you can advance the `virtual_time` up to 80 weeks on each API call.
     # @param sandbox_transfer_test_clock_advance_request [SandboxTransferTestClockAdvanceRequest] 
     # @param [Hash] opts the optional parameters
     # @return [SandboxTransferTestClockAdvanceResponse]
@@ -7765,7 +7765,7 @@ module Plaid
     end
 
     # Advance a test clock
-    # Use the &#x60;/sandbox/transfer/test_clock/advance&#x60; endpoint to advance a &#x60;test_clock&#x60; in the Sandbox environment.   A test clock object represents an independent timeline and has a &#x60;frozen_timestamp&#x60; field indicating the current timestamp of the timeline. A test clock can be advanced by incrementing &#x60;frozen_timestamp&#x60;, but may never go back to a lower &#x60;frozen_timestamp&#x60;.  If a test clock is advanced from T1 to T2, we will simulate the changes that ought to occur during the period of (T1, T2].  For instance, a client creates a weekly recurring transfer with a test clock set at t. When the client advances the test clock by setting &#x60;frozen_timestamp&#x60; &#x3D; t + 15 days, 2 new originations should be created, along with the webhook events. The timestamps of the objects and webhook events created/updated in step 2 should also fall in (T1, T2] time range.  The advancement of the test clock from its current &#x60;frozen_timestamp&#x60; should be limited such that there are no more than 20 originations resulted from the advance operation on each &#x60;recurring_transfer&#x60; associated with this &#x60;test_clock&#x60;.  For instance, if the recurring transfer associated with this test clock originates once every 4 weeks, you can advance the &#x60;frozen_timestamp&#x60; up to 80 weeks on each advance call.
+    # Use the &#x60;/sandbox/transfer/test_clock/advance&#x60; endpoint to advance a &#x60;test_clock&#x60; in the Sandbox environment.  A test clock object represents an independent timeline and has a &#x60;virtual_time&#x60; field indicating the current timestamp of the timeline. A test clock can be advanced by incrementing &#x60;virtual_time&#x60;, but may never go back to a lower &#x60;virtual_time&#x60;.  If a test clock is advanced, we will simulate the changes that ought to occur during the time that elapsed. For instance, a client creates a weekly recurring transfer with a test clock set at t. When the client advances the test clock by setting &#x60;virtual_time&#x60; &#x3D; t + 15 days, 2 new originations should be created, along with the webhook events.  The advancement of the test clock from its current &#x60;virtual_time&#x60; should be limited such that there are no more than 20 originations resulting from the advance operation on each &#x60;recurring_transfer&#x60; associated with the &#x60;test_clock&#x60;. For instance, if the recurring transfer associated with this test clock originates once every 4 weeks, you can advance the &#x60;virtual_time&#x60; up to 80 weeks on each API call.
     # @param sandbox_transfer_test_clock_advance_request [SandboxTransferTestClockAdvanceRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(SandboxTransferTestClockAdvanceResponse, Integer, Hash)>] SandboxTransferTestClockAdvanceResponse data, response status code and response headers
@@ -7820,7 +7820,7 @@ module Plaid
     end
 
     # Create a test clock
-    # Use the `/sandbox/transfer/test_clock/create` endpoint to create a `test_clock` in the Sandbox environment.   A test clock object represents an independent timeline and has a `frozen_timestamp` field indicating the current timestamp of the timeline. Test clock allows clients to easily test and integrate with recurring transfer product in sandbox environment.  A test clock can be associated with up to 5 recurring transfers.
+    # Use the `/sandbox/transfer/test_clock/create` endpoint to create a `test_clock` in the Sandbox environment.  A test clock object represents an independent timeline and has a `virtual_time` field indicating the current timestamp of the timeline. Test clocks are used for testing recurring transfers in Sandbox.  A test clock can be associated with up to 5 recurring transfers.
     # @param sandbox_transfer_test_clock_create_request [SandboxTransferTestClockCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [SandboxTransferTestClockCreateResponse]
@@ -7830,7 +7830,7 @@ module Plaid
     end
 
     # Create a test clock
-    # Use the &#x60;/sandbox/transfer/test_clock/create&#x60; endpoint to create a &#x60;test_clock&#x60; in the Sandbox environment.   A test clock object represents an independent timeline and has a &#x60;frozen_timestamp&#x60; field indicating the current timestamp of the timeline. Test clock allows clients to easily test and integrate with recurring transfer product in sandbox environment.  A test clock can be associated with up to 5 recurring transfers.
+    # Use the &#x60;/sandbox/transfer/test_clock/create&#x60; endpoint to create a &#x60;test_clock&#x60; in the Sandbox environment.  A test clock object represents an independent timeline and has a &#x60;virtual_time&#x60; field indicating the current timestamp of the timeline. Test clocks are used for testing recurring transfers in Sandbox.  A test clock can be associated with up to 5 recurring transfers.
     # @param sandbox_transfer_test_clock_create_request [SandboxTransferTestClockCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(SandboxTransferTestClockCreateResponse, Integer, Hash)>] SandboxTransferTestClockCreateResponse data, response status code and response headers
@@ -7949,6 +7949,71 @@ module Plaid
       return data, status_code, headers
     end
 
+    # List test clocks
+    # Use the `/sandbox/transfer/test_clock/list` endpoint to see a list of all your test clocks in the Sandbox environment, by ascending `virtual_time`. Results are paginated; use the `count` and `offset` query parameters to retrieve the desired test clocks.
+    # @param sandbox_transfer_test_clock_list_request [SandboxTransferTestClockListRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [SandboxTransferTestClockListResponse]
+    def sandbox_transfer_test_clock_list(sandbox_transfer_test_clock_list_request, opts = {})
+      data, _status_code, _headers = sandbox_transfer_test_clock_list_with_http_info(sandbox_transfer_test_clock_list_request, opts)
+      data
+    end
+
+    # List test clocks
+    # Use the &#x60;/sandbox/transfer/test_clock/list&#x60; endpoint to see a list of all your test clocks in the Sandbox environment, by ascending &#x60;virtual_time&#x60;. Results are paginated; use the &#x60;count&#x60; and &#x60;offset&#x60; query parameters to retrieve the desired test clocks.
+    # @param sandbox_transfer_test_clock_list_request [SandboxTransferTestClockListRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [Array<(SandboxTransferTestClockListResponse, Integer, Hash)>] SandboxTransferTestClockListResponse data, response status code and response headers
+    def sandbox_transfer_test_clock_list_with_http_info(sandbox_transfer_test_clock_list_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: PlaidApi.sandbox_transfer_test_clock_list ...'
+      end
+      # verify the required parameter 'sandbox_transfer_test_clock_list_request' is set
+      if @api_client.config.client_side_validation && sandbox_transfer_test_clock_list_request.nil?
+        fail ArgumentError, "Missing the required parameter 'sandbox_transfer_test_clock_list_request' when calling PlaidApi.sandbox_transfer_test_clock_list"
+      end
+      # resource path
+      local_var_path = '/sandbox/transfer/test_clock/list'
+
+      # query parameters
+      query_params = opts[:query_params] || {}
+
+      # header parameters
+      header_params = opts[:header_params] || {}
+      # HTTP header 'Accept' (if needed)
+      header_params['Accept'] = @api_client.select_header_accept(['application/json'])
+      # HTTP header 'Content-Type'
+      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json'])
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(sandbox_transfer_test_clock_list_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'SandboxTransferTestClockListResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+
+      new_options = opts.merge(
+        :operation => :"PlaidApi.sandbox_transfer_test_clock_list",
+        :header_params => header_params,
+        :query_params => query_params,
+        :form_params => form_params,
+        :body => post_body,
+        :auth_names => auth_names,
+        :return_type => return_type
+      )
+
+      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
+      if @api_client.config.debugging
+        @api_client.config.logger.debug "API called: PlaidApi#sandbox_transfer_test_clock_list\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
+
     # Report whether you initiated an ACH transaction
     # After calling `/signal/evaluate`, call `/signal/decision/report` to report whether the transaction was initiated. This endpoint will return an [`INVALID_FIELD`](/docs/errors/invalid-request/#invalid_field) error if called a second time with a different value for `initiated`.
     # @param signal_decision_report_request [SignalDecisionReportRequest] 
@@ -8210,7 +8275,7 @@ module Plaid
     end
 
     # enhance locally-held transaction data
-    # The '/beta/transactions/v1/enhance' endpoint enriches raw transaction data provided directly by clients.  The product is currently in beta.
+    # The `/beta/transactions/v1/enhance` endpoint enriches raw transaction data provided directly by clients.  The product is currently in beta.
     # @param transactions_enhance_get_request [TransactionsEnhanceGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransactionsEnhanceGetResponse]
@@ -8220,7 +8285,7 @@ module Plaid
     end
 
     # enhance locally-held transaction data
-    # The &#39;/beta/transactions/v1/enhance&#39; endpoint enriches raw transaction data provided directly by clients.  The product is currently in beta.
+    # The &#x60;/beta/transactions/v1/enhance&#x60; endpoint enriches raw transaction data provided directly by clients.  The product is currently in beta.
     # @param transactions_enhance_get_request [TransactionsEnhanceGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransactionsEnhanceGetResponse, Integer, Hash)>] TransactionsEnhanceGetResponse data, response status code and response headers
@@ -8275,7 +8340,7 @@ module Plaid
     end
 
     # Enrich locally-held transaction data
-    # The '/transactions/enrich' endpoint enriches raw transaction data generated by your own banking products or retrieved from other non-Plaid sources.  The product is currently in beta. To request access, contact transactions-feedback@plaid.com
+    # The `/transactions/enrich` endpoint enriches raw transaction data generated by your own banking products or retrieved from other non-Plaid sources.  The product is currently in beta. To request access, contact enrich-feedback@plaid.com
     # @param transactions_enrich_get_request [TransactionsEnrichGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransactionsEnrichGetResponse]
@@ -8285,7 +8350,7 @@ module Plaid
     end
 
     # Enrich locally-held transaction data
-    # The &#39;/transactions/enrich&#39; endpoint enriches raw transaction data generated by your own banking products or retrieved from other non-Plaid sources.  The product is currently in beta. To request access, contact transactions-feedback@plaid.com
+    # The &#x60;/transactions/enrich&#x60; endpoint enriches raw transaction data generated by your own banking products or retrieved from other non-Plaid sources.  The product is currently in beta. To request access, contact enrich-feedback@plaid.com
     # @param transactions_enrich_get_request [TransactionsEnrichGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransactionsEnrichGetResponse, Integer, Hash)>] TransactionsEnrichGetResponse data, response status code and response headers
@@ -8405,7 +8470,7 @@ module Plaid
     end
 
     # Fetch recurring transaction streams
-    # The `/transactions/recurring/get` endpoint allows developers to receive a summary of the recurring outflow and inflow streams (expenses and deposits) from a user’s checking, savings or credit card accounts. Additionally, Plaid provides key insights about each recurring stream including the category, merchant, last amount, and more. Developers can use these insights to build tools and experiences that help their users better manage cash flow, monitor subscriptions, reduce spend, and stay on track with bill payments.  This endpoint is not included by default as part of Transactions. To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.  Note that unlike `/transactions/get`, `/transactions/recurring/get` will not initialize an Item with Transactions. The Item must already have been initialized with Transactions (either during Link, by specifying it in `/link/token/create`, or after Link, by calling `/transactions/get`) before calling this endpoint. Data is available to `/transactions/recurring/get` approximately 5 seconds after the [`HISTORICAL_UPDATE`](https://plaid.com/docs/api/products/transactions/#historical_update) webhook has fired (about 1-2 minutes after initialization).  After the initial call, you can call `/transactions/recurring/get` endpoint at any point in the future to retrieve the latest summary of recurring streams. Since recurring streams do not change often, it will typically not be necessary to call this endpoint more than once per day.
+    # The `/transactions/recurring/get` endpoint allows developers to receive a summary of the recurring outflow and inflow streams (expenses and deposits) from a user’s checking, savings or credit card accounts. Additionally, Plaid provides key insights about each recurring stream including the category, merchant, last amount, and more. Developers can use these insights to build tools and experiences that help their users better manage cash flow, monitor subscriptions, reduce spend, and stay on track with bill payments.  This endpoint is not included by default as part of Transactions. To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.  This endpoint can only be called on an Item that has already been initialized with Transactions (either during Link, by specifying it in `/link/token/create`; or after Link, by calling `/transactions/get`). After the [`HISTORICAL_UPDATE`](https://plaid.com/docs/api/products/transactions/#historical_update) webhook has fired, call `/transactions/recurring/get` to receive the Recurring Transactions streams and subscribe to the [`RECURRING_TRANSACTIONS_UPDATE`](https://plaid.com/docs/api/products/transactions/#recurring_transactions_update) webhook.  After the initial call, you can call `/transactions/recurring/get` endpoint at any point in the future to retrieve the latest summary of recurring streams. Listen to the [`RECURRING_TRANSACTIONS_UPDATE`](https://plaid.com/docs/api/products/transactions/#recurring_transactions_update) webhook to be notified when new updates are available.
     # @param transactions_recurring_get_request [TransactionsRecurringGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransactionsRecurringGetResponse]
@@ -8415,7 +8480,7 @@ module Plaid
     end
 
     # Fetch recurring transaction streams
-    # The &#x60;/transactions/recurring/get&#x60; endpoint allows developers to receive a summary of the recurring outflow and inflow streams (expenses and deposits) from a user’s checking, savings or credit card accounts. Additionally, Plaid provides key insights about each recurring stream including the category, merchant, last amount, and more. Developers can use these insights to build tools and experiences that help their users better manage cash flow, monitor subscriptions, reduce spend, and stay on track with bill payments.  This endpoint is not included by default as part of Transactions. To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.  Note that unlike &#x60;/transactions/get&#x60;, &#x60;/transactions/recurring/get&#x60; will not initialize an Item with Transactions. The Item must already have been initialized with Transactions (either during Link, by specifying it in &#x60;/link/token/create&#x60;, or after Link, by calling &#x60;/transactions/get&#x60;) before calling this endpoint. Data is available to &#x60;/transactions/recurring/get&#x60; approximately 5 seconds after the [&#x60;HISTORICAL_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#historical_update) webhook has fired (about 1-2 minutes after initialization).  After the initial call, you can call &#x60;/transactions/recurring/get&#x60; endpoint at any point in the future to retrieve the latest summary of recurring streams. Since recurring streams do not change often, it will typically not be necessary to call this endpoint more than once per day.
+    # The &#x60;/transactions/recurring/get&#x60; endpoint allows developers to receive a summary of the recurring outflow and inflow streams (expenses and deposits) from a user’s checking, savings or credit card accounts. Additionally, Plaid provides key insights about each recurring stream including the category, merchant, last amount, and more. Developers can use these insights to build tools and experiences that help their users better manage cash flow, monitor subscriptions, reduce spend, and stay on track with bill payments.  This endpoint is not included by default as part of Transactions. To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.  This endpoint can only be called on an Item that has already been initialized with Transactions (either during Link, by specifying it in &#x60;/link/token/create&#x60;; or after Link, by calling &#x60;/transactions/get&#x60;). After the [&#x60;HISTORICAL_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#historical_update) webhook has fired, call &#x60;/transactions/recurring/get&#x60; to receive the Recurring Transactions streams and subscribe to the [&#x60;RECURRING_TRANSACTIONS_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#recurring_transactions_update) webhook.  After the initial call, you can call &#x60;/transactions/recurring/get&#x60; endpoint at any point in the future to retrieve the latest summary of recurring streams. Listen to the [&#x60;RECURRING_TRANSACTIONS_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#recurring_transactions_update) webhook to be notified when new updates are available.
     # @param transactions_recurring_get_request [TransactionsRecurringGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransactionsRecurringGetResponse, Integer, Hash)>] TransactionsRecurringGetResponse data, response status code and response headers
@@ -8730,7 +8795,7 @@ module Plaid
     end
 
     # Get incremental transaction updates on an Item
-    # This endpoint replaces `/transactions/get` and its associated webhooks for most common use-cases.  The `/transactions/sync` endpoint allows developers to subscribe to all transactions associated with an Item and get updates synchronously in a stream-like manner, using a cursor to track which updates have already been seen. `/transactions/sync` provides the same functionality as `/transactions/get` and can be used instead of `/transactions/get` to simplify the process of tracking transactions updates.  This endpoint provides user-authorized transaction data for `credit`, `depository`, and some loan-type accounts (only those with account subtype `student`; coverage may be limited). For transaction history from `investments` accounts, use `/investments/transactions/get` instead.  Returned transactions data is grouped into three types of update, indicating whether the transaction was added, removed, or modified since the last call to the API.  In the first call to `/transactions/sync` for an Item, the endpoint will return all historical transactions data associated with that Item up until the time of the API call (as \"adds\"), which then generates a `next_cursor` for that Item. In subsequent calls, send the `next_cursor` to receive only the changes that have occurred since the previous call.  Due to the potentially large number of transactions associated with an Item, results are paginated. The `has_more` field specifies if additional calls are necessary to fetch all available transaction updates. Call `/transactions/sync` with the new cursor, pulling all updates, until `has_more` is `false`.   When retrieving paginated updates, track both the `next_cursor` from the latest response and the original cursor from the first call in which `has_more` was `true`; if a call to `/transactions/sync` fails when retrieving a paginated update, the entire pagination request loop must be restarted beginning with the cursor for the first page of the update, rather than retrying only the single request that failed.   Whenever new or updated transaction data becomes available, `/transactions/sync` will provide these updates. Plaid typically checks for new data multiple times a day, but these checks may occur less frequently, such as once a day, depending on the institution. An Item's `status.transactions.last_successful_update` field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, use the `/transactions/refresh` endpoint.  Note that for newly created Items, data may not be immediately available to `/transactions/sync`. Plaid begins preparing transactions data when the Item is created, but the process can take anywhere from a few seconds to several minutes to complete, depending on the number of transactions available.  To be alerted when new data is available, listen for the [`SYNC_UPDATES_AVAILABLE`](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.
+    # This endpoint replaces `/transactions/get` and its associated webhooks for most common use-cases.  The `/transactions/sync` endpoint allows developers to subscribe to all transactions associated with an Item and get updates synchronously in a stream-like manner, using a cursor to track which updates have already been seen. `/transactions/sync` provides the same functionality as `/transactions/get` and can be used instead of `/transactions/get` to simplify the process of tracking transactions updates.  This endpoint provides user-authorized transaction data for `credit`, `depository`, and some loan-type accounts (only those with account subtype `student`; coverage may be limited). For transaction history from `investments` accounts, use `/investments/transactions/get` instead.  Returned transactions data is grouped into three types of update, indicating whether the transaction was added, removed, or modified since the last call to the API.  In the first call to `/transactions/sync` for an Item, the endpoint will return all historical transactions data associated with that Item up until the time of the API call (as \"adds\"), which then generates a `next_cursor` for that Item. In subsequent calls, send the `next_cursor` to receive only the changes that have occurred since the previous call.  Due to the potentially large number of transactions associated with an Item, results are paginated. The `has_more` field specifies if additional calls are necessary to fetch all available transaction updates. Call `/transactions/sync` with the new cursor, pulling all updates, until `has_more` is `false`.  When retrieving paginated updates, track both the `next_cursor` from the latest response and the original cursor from the first call in which `has_more` was `true`; if a call to `/transactions/sync` fails when retrieving a paginated update, the entire pagination request loop must be restarted beginning with the cursor for the first page of the update, rather than retrying only the single request that failed.  Whenever new or updated transaction data becomes available, `/transactions/sync` will provide these updates. Plaid typically checks for new data multiple times a day, but these checks may occur less frequently, such as once a day, depending on the institution. An Item's `status.transactions.last_successful_update` field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, use the `/transactions/refresh` endpoint.  Note that for newly created Items, data may not be immediately available to `/transactions/sync`. Plaid begins preparing transactions data when the Item is created, but the process can take anywhere from a few seconds to several minutes to complete, depending on the number of transactions available.  To be alerted when new data is available, listen for the [`SYNC_UPDATES_AVAILABLE`](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.
     # @param transactions_sync_request [TransactionsSyncRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransactionsSyncResponse]
@@ -8740,7 +8805,7 @@ module Plaid
     end
 
     # Get incremental transaction updates on an Item
-    # This endpoint replaces &#x60;/transactions/get&#x60; and its associated webhooks for most common use-cases.  The &#x60;/transactions/sync&#x60; endpoint allows developers to subscribe to all transactions associated with an Item and get updates synchronously in a stream-like manner, using a cursor to track which updates have already been seen. &#x60;/transactions/sync&#x60; provides the same functionality as &#x60;/transactions/get&#x60; and can be used instead of &#x60;/transactions/get&#x60; to simplify the process of tracking transactions updates.  This endpoint provides user-authorized transaction data for &#x60;credit&#x60;, &#x60;depository&#x60;, and some loan-type accounts (only those with account subtype &#x60;student&#x60;; coverage may be limited). For transaction history from &#x60;investments&#x60; accounts, use &#x60;/investments/transactions/get&#x60; instead.  Returned transactions data is grouped into three types of update, indicating whether the transaction was added, removed, or modified since the last call to the API.  In the first call to &#x60;/transactions/sync&#x60; for an Item, the endpoint will return all historical transactions data associated with that Item up until the time of the API call (as \&quot;adds\&quot;), which then generates a &#x60;next_cursor&#x60; for that Item. In subsequent calls, send the &#x60;next_cursor&#x60; to receive only the changes that have occurred since the previous call.  Due to the potentially large number of transactions associated with an Item, results are paginated. The &#x60;has_more&#x60; field specifies if additional calls are necessary to fetch all available transaction updates. Call &#x60;/transactions/sync&#x60; with the new cursor, pulling all updates, until &#x60;has_more&#x60; is &#x60;false&#x60;.   When retrieving paginated updates, track both the &#x60;next_cursor&#x60; from the latest response and the original cursor from the first call in which &#x60;has_more&#x60; was &#x60;true&#x60;; if a call to &#x60;/transactions/sync&#x60; fails when retrieving a paginated update, the entire pagination request loop must be restarted beginning with the cursor for the first page of the update, rather than retrying only the single request that failed.   Whenever new or updated transaction data becomes available, &#x60;/transactions/sync&#x60; will provide these updates. Plaid typically checks for new data multiple times a day, but these checks may occur less frequently, such as once a day, depending on the institution. An Item&#39;s &#x60;status.transactions.last_successful_update&#x60; field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, use the &#x60;/transactions/refresh&#x60; endpoint.  Note that for newly created Items, data may not be immediately available to &#x60;/transactions/sync&#x60;. Plaid begins preparing transactions data when the Item is created, but the process can take anywhere from a few seconds to several minutes to complete, depending on the number of transactions available.  To be alerted when new data is available, listen for the [&#x60;SYNC_UPDATES_AVAILABLE&#x60;](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.
+    # This endpoint replaces &#x60;/transactions/get&#x60; and its associated webhooks for most common use-cases.  The &#x60;/transactions/sync&#x60; endpoint allows developers to subscribe to all transactions associated with an Item and get updates synchronously in a stream-like manner, using a cursor to track which updates have already been seen. &#x60;/transactions/sync&#x60; provides the same functionality as &#x60;/transactions/get&#x60; and can be used instead of &#x60;/transactions/get&#x60; to simplify the process of tracking transactions updates.  This endpoint provides user-authorized transaction data for &#x60;credit&#x60;, &#x60;depository&#x60;, and some loan-type accounts (only those with account subtype &#x60;student&#x60;; coverage may be limited). For transaction history from &#x60;investments&#x60; accounts, use &#x60;/investments/transactions/get&#x60; instead.  Returned transactions data is grouped into three types of update, indicating whether the transaction was added, removed, or modified since the last call to the API.  In the first call to &#x60;/transactions/sync&#x60; for an Item, the endpoint will return all historical transactions data associated with that Item up until the time of the API call (as \&quot;adds\&quot;), which then generates a &#x60;next_cursor&#x60; for that Item. In subsequent calls, send the &#x60;next_cursor&#x60; to receive only the changes that have occurred since the previous call.  Due to the potentially large number of transactions associated with an Item, results are paginated. The &#x60;has_more&#x60; field specifies if additional calls are necessary to fetch all available transaction updates. Call &#x60;/transactions/sync&#x60; with the new cursor, pulling all updates, until &#x60;has_more&#x60; is &#x60;false&#x60;.  When retrieving paginated updates, track both the &#x60;next_cursor&#x60; from the latest response and the original cursor from the first call in which &#x60;has_more&#x60; was &#x60;true&#x60;; if a call to &#x60;/transactions/sync&#x60; fails when retrieving a paginated update, the entire pagination request loop must be restarted beginning with the cursor for the first page of the update, rather than retrying only the single request that failed.  Whenever new or updated transaction data becomes available, &#x60;/transactions/sync&#x60; will provide these updates. Plaid typically checks for new data multiple times a day, but these checks may occur less frequently, such as once a day, depending on the institution. An Item&#39;s &#x60;status.transactions.last_successful_update&#x60; field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, use the &#x60;/transactions/refresh&#x60; endpoint.  Note that for newly created Items, data may not be immediately available to &#x60;/transactions/sync&#x60;. Plaid begins preparing transactions data when the Item is created, but the process can take anywhere from a few seconds to several minutes to complete, depending on the number of transactions available.  To be alerted when new data is available, listen for the [&#x60;SYNC_UPDATES_AVAILABLE&#x60;](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.
     # @param transactions_sync_request [TransactionsSyncRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransactionsSyncResponse, Integer, Hash)>] TransactionsSyncResponse data, response status code and response headers
@@ -8924,6 +8989,71 @@ module Plaid
       return data, status_code, headers
     end
 
+    # Get RTP eligibility information of a transfer
+    # Use the `/transfer/capabilities/get` endpoint to determine the RTP eligibility information of a transfer.
+    # @param transfer_capabilities_get_request [TransferCapabilitiesGetRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [TransferCapabilitiesGetResponse]
+    def transfer_capabilities_get(transfer_capabilities_get_request, opts = {})
+      data, _status_code, _headers = transfer_capabilities_get_with_http_info(transfer_capabilities_get_request, opts)
+      data
+    end
+
+    # Get RTP eligibility information of a transfer
+    # Use the &#x60;/transfer/capabilities/get&#x60; endpoint to determine the RTP eligibility information of a transfer.
+    # @param transfer_capabilities_get_request [TransferCapabilitiesGetRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [Array<(TransferCapabilitiesGetResponse, Integer, Hash)>] TransferCapabilitiesGetResponse data, response status code and response headers
+    def transfer_capabilities_get_with_http_info(transfer_capabilities_get_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: PlaidApi.transfer_capabilities_get ...'
+      end
+      # verify the required parameter 'transfer_capabilities_get_request' is set
+      if @api_client.config.client_side_validation && transfer_capabilities_get_request.nil?
+        fail ArgumentError, "Missing the required parameter 'transfer_capabilities_get_request' when calling PlaidApi.transfer_capabilities_get"
+      end
+      # resource path
+      local_var_path = '/transfer/capabilities/get'
+
+      # query parameters
+      query_params = opts[:query_params] || {}
+
+      # header parameters
+      header_params = opts[:header_params] || {}
+      # HTTP header 'Accept' (if needed)
+      header_params['Accept'] = @api_client.select_header_accept(['application/json'])
+      # HTTP header 'Content-Type'
+      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json'])
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(transfer_capabilities_get_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'TransferCapabilitiesGetResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+
+      new_options = opts.merge(
+        :operation => :"PlaidApi.transfer_capabilities_get",
+        :header_params => header_params,
+        :query_params => query_params,
+        :form_params => form_params,
+        :body => post_body,
+        :auth_names => auth_names,
+        :return_type => return_type
+      )
+
+      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
+      if @api_client.config.debugging
+        @api_client.config.logger.debug "API called: PlaidApi#transfer_capabilities_get\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
+
     # Create a transfer
     # Use the `/transfer/create` endpoint to initiate a new transfer.
     # @param transfer_create_request [TransferCreateRequest] 

data/lib/plaid/api_client.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1
@@ -34,7 +34,7 @@ module Plaid
     # @option config [Configuration] Configuration for initializing the object, default to Configuration.default
     def initialize(config = Configuration.default)
       @config = config
-      @user_agent = "Plaid Ruby v17.1.0"
+      @user_agent = "Plaid Ruby v17.2.0"
       @default_headers = {
         'Content-Type' => 'application/json',
         'User-Agent' => @user_agent,
@@ -77,10 +77,17 @@ module Plaid
             fail ApiError.new(:code => 0,
                               :message => response.return_message)
           else
+            raw_body = response.body
+            # Gracefully handle malformed body which is possible during API outage/maintanance
+            parsed_body = begin
+               JSON.parse(raw_body)
+             rescue JSON::ParserError
+               nil
+             end
             fail ApiError.new(:code => response.status,
                               :response_headers => response.headers,
-                              :response_body => response.body,
-                              :data => JSON.parse(response.body)),
+                              :response_body => raw_body,
+                              :data => parsed_body),
                  response.reason_phrase
           end
         end

data/lib/plaid/api_error.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1

data/lib/plaid/configuration.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1

data/lib/plaid/models/account_access.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1

data/lib/plaid/models/account_assets.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1

data/lib/plaid/models/account_assets_all_of.rb

@@ -3,7 +3,7 @@
 
 #The Plaid REST API. Please see https://plaid.com/docs/api for more details.
 
-The version of the OpenAPI document: 2020-09-14_1.205.3
+The version of the OpenAPI document: 2020-09-14_1.210.4
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 5.1.1