plaid 52.0.0 → 53.0.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.762.0
+The version of the OpenAPI document: 2020-09-14_1.778.0
 
 Generated by: https://openapi-generator.tech
 OpenAPI Generator version: 6.3.0
@@ -2603,6 +2603,74 @@ module Plaid
       return data, status_code, headers
     end
 
+    # Get Cash Advance income insights
+    # The `/beta/cash_advance/income_insights/v1/get` endpoint returns a user's top income streams across all of the user's active Items, ranked by historical net monthly income and capped at three, along with the next payment date and amount of the highest-ranked stream.  Only USD income streams are returned. If some, but not all, of the user's Items could not be evaluated, the response is based on the remaining Items.
+    # @param beta_cash_advance_income_insights_v1_get_request [BetaCashAdvanceIncomeInsightsV1GetRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [BetaCashAdvanceIncomeInsightsV1GetResponse]
+    def beta_cash_advance_income_insights_v1_get(beta_cash_advance_income_insights_v1_get_request, opts = {})
+      data, _status_code, _headers = beta_cash_advance_income_insights_v1_get_with_http_info(beta_cash_advance_income_insights_v1_get_request, opts)
+      data
+    end
+
+    # Get Cash Advance income insights
+    # The `/beta/cash_advance/income_insights/v1/get` endpoint returns a user's top income streams across all of the user's active Items, ranked by historical net monthly income and capped at three, along with the next payment date and amount of the highest-ranked stream.  Only USD income streams are returned. If some, but not all, of the user's Items could not be evaluated, the response is based on the remaining Items.
+    # @param beta_cash_advance_income_insights_v1_get_request [BetaCashAdvanceIncomeInsightsV1GetRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [Array<(BetaCashAdvanceIncomeInsightsV1GetResponse, Integer, Hash)>] BetaCashAdvanceIncomeInsightsV1GetResponse data, response status code and response headers
+    def beta_cash_advance_income_insights_v1_get_with_http_info(beta_cash_advance_income_insights_v1_get_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: PlaidApi.beta_cash_advance_income_insights_v1_get ...'
+      end
+      # verify the required parameter 'beta_cash_advance_income_insights_v1_get_request' is set
+      if @api_client.config.client_side_validation && beta_cash_advance_income_insights_v1_get_request.nil?
+        fail ArgumentError, "Missing the required parameter 'beta_cash_advance_income_insights_v1_get_request' when calling PlaidApi.beta_cash_advance_income_insights_v1_get"
+      end
+      # resource path
+      local_var_path = '/beta/cash_advance/income_insights/v1/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'
+      content_type = @api_client.select_header_content_type(['application/json'])
+      if !content_type.nil?
+          header_params['Content-Type'] = content_type
+      end
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(beta_cash_advance_income_insights_v1_get_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'BetaCashAdvanceIncomeInsightsV1GetResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+
+      new_options = opts.merge(
+        :operation => :"PlaidApi.beta_cash_advance_income_insights_v1_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#beta_cash_advance_income_insights_v1_get\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
+
     # Get EWA Score Report
     # The `/beta/ewa_report/v1/get` endpoint provides an Earned Wage Access (EWA) score that quantifies the delinquency risk associated with a given item. The score is derived from a combination of cashflow patterns and network-based behavioral features.  The response returns a list of EWA scores, where each score corresponds to a potential advance amount range. These scores estimate the likelihood of repayment for advances within that range.  Score range: 1-99  Interpretation: Higher scores indicate a greater likelihood of repayment.  This endpoint enables clients to assess repayment risk and make data-driven decisions when determining eligibility or limits for earned wage advances.
     # @param beta_ewa_report_v1_get_request [BetaEwaReportV1GetRequest] 
@@ -2720,7 +2788,7 @@ module Plaid
       return_type = opts[:debug_return_type] || 'BetaIssuesV1GetResponse'
 
       # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+      auth_names = opts[:debug_auth_names] || ['clientId', 'oauth2', 'plaidVersion', 'secret']
 
       new_options = opts.merge(
         :operation => :"PlaidApi.beta_issues_v1_get",
@@ -2856,7 +2924,7 @@ module Plaid
       return_type = opts[:debug_return_type] || 'BetaIssuesV1MatchResponse'
 
       # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+      auth_names = opts[:debug_auth_names] || ['clientId', 'oauth2', 'plaidVersion', 'secret']
 
       new_options = opts.merge(
         :operation => :"PlaidApi.beta_issues_v1_match",
@@ -2876,7 +2944,7 @@ module Plaid
     end
 
     # Subscribe to an issue
-    # Subscribe a webhook URL to resolution notifications for an institution issue.
+    # Subscribe a webhook URL to resolution notifications for an institution issue. A client has a single subscription per issue, so subscribing again for the same issue overwrites the previously registered webhook URL.
     # @param beta_issues_v1_subscribe_request [BetaIssuesV1SubscribeRequest] 
     # @param [Hash] opts the optional parameters
     # @return [BetaIssuesV1SubscribeResponse]
@@ -2886,7 +2954,7 @@ module Plaid
     end
 
     # Subscribe to an issue
-    # Subscribe a webhook URL to resolution notifications for an institution issue.
+    # Subscribe a webhook URL to resolution notifications for an institution issue. A client has a single subscription per issue, so subscribing again for the same issue overwrites the previously registered webhook URL.
     # @param beta_issues_v1_subscribe_request [BetaIssuesV1SubscribeRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(BetaIssuesV1SubscribeResponse, Integer, Hash)>] BetaIssuesV1SubscribeResponse data, response status code and response headers
@@ -2924,7 +2992,7 @@ module Plaid
       return_type = opts[:debug_return_type] || 'BetaIssuesV1SubscribeResponse'
 
       # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+      auth_names = opts[:debug_auth_names] || ['clientId', 'oauth2', 'plaidVersion', 'secret']
 
       new_options = opts.merge(
         :operation => :"PlaidApi.beta_issues_v1_subscribe",
@@ -2944,7 +3012,7 @@ module Plaid
     end
 
     # Unsubscribe from an issue
-    # Remove the client's subscription to resolution notifications for an institution issue.
+    # Remove the client's subscription to resolution notifications for an institution issue. This removes the client's single subscription for that issue, identified by the issue alone.
     # @param beta_issues_v1_unsubscribe_request [BetaIssuesV1UnsubscribeRequest] 
     # @param [Hash] opts the optional parameters
     # @return [BetaIssuesV1UnsubscribeResponse]
@@ -2954,7 +3022,7 @@ module Plaid
     end
 
     # Unsubscribe from an issue
-    # Remove the client&#39;s subscription to resolution notifications for an institution issue.
+    # Remove the client&#39;s subscription to resolution notifications for an institution issue. This removes the client&#39;s single subscription for that issue, identified by the issue alone.
     # @param beta_issues_v1_unsubscribe_request [BetaIssuesV1UnsubscribeRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(BetaIssuesV1UnsubscribeResponse, Integer, Hash)>] BetaIssuesV1UnsubscribeResponse data, response status code and response headers
@@ -2992,7 +3060,7 @@ module Plaid
       return_type = opts[:debug_return_type] || 'BetaIssuesV1UnsubscribeResponse'
 
       # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+      auth_names = opts[:debug_auth_names] || ['clientId', 'oauth2', 'plaidVersion', 'secret']
 
       new_options = opts.merge(
         :operation => :"PlaidApi.beta_issues_v1_unsubscribe",
@@ -3284,7 +3352,7 @@ module Plaid
     end
 
     # List webhook events
-    # `/beta/webhook_events/list` returns webhook events for your account from the last 7 days, regardless of delivery outcome. Results are ordered by `sent_time`, oldest first, and paginated with a cursor so you can recover deliveries your endpoint missed. Each event includes a `webhook_message_id` that stays the same if that event shows up again on a later poll, so you can skip events you have already handled.  `TRANSACTIONS` webhooks are not returned. Use [`/transactions/sync`](https://plaid.com/docs/api/products/transactions/#transactionssync) to recover transaction updates.  Filtering is optional. For `webhook_types`, `webhook_codes`, `item_ids`, and `delivery_statuses`, values within a field match with OR; different fields combine with AND. For example, `webhook_types: [\"ITEM\", \"AUTH\"]` matches events of either type.  To page through events:  - On the first request, omit `cursor`. You can set `start_time` to a time within the last 7 days, or omit `start_time` to start at the oldest retained event. - On later requests, send the previous response's `next_cursor` as `cursor`. If you also send `start_time`, it is ignored; `cursor` takes precedence, even when `start_time` has changed. - Save `next_cursor` even when `has_more` is `false`, and send that cursor on the next poll so you only receive events newer than the ones you have already seen.  A request fails with 400 in these cases:  - `WEBHOOK_EVENTS_START_TIME_OUT_OF_RANGE` (`INVALID_INPUT`) is returned when `cursor` is omitted and `start_time` is earlier than the 7-day retention window. Retry with a `start_time` within the last 7 days, or omit `start_time`. - `WEBHOOK_EVENTS_CURSOR_EXPIRED` (`INVALID_INPUT`) is returned when the cursor is older than the 7-day retention window and can no longer be resolved. Start again with a `start_time` within the last 7 days. Events older than that window are no longer available. - `INVALID_FIELD` (`INVALID_REQUEST`) is returned when `cursor` is not a properly formatted string, or when the request is otherwise invalid.  This endpoint is in beta and may change in backwards-incompatible ways before it is generally available. Send feedback or bug reports to building@plaid.com.
+    # `/beta/webhook_events/list` returns the webhooks Plaid sent to your account in the last 7 days, including webhooks that weren't delivered. Use it to recover webhooks your endpoint missed. Events are returned oldest first.  `TRANSACTIONS` webhooks are not included. To recover Transactions updates, use [`/transactions/sync`](https://plaid.com/docs/api/products/transactions/#transactionssync).  To page through events, omit `cursor` on your first request, then pass the previous response's `next_cursor` on each later request. Store `next_cursor` even when `has_more` is `false`, so your next poll returns only newer events.  Filters are optional. An event matches a filter if it matches any of the filter's values, and must match every filter you provide.  Events older than 7 days are not retained. If your cursor or `start_time` is older than that, the request fails with `WEBHOOK_EVENTS_CURSOR_EXPIRED` or `WEBHOOK_EVENTS_START_TIME_OUT_OF_RANGE`.  This endpoint is in beta and may change in backwards-incompatible ways. Send feedback to building@plaid.com.
     # @param beta_webhook_events_list_request [BetaWebhookEventsListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [BetaWebhookEventsListResponse]
@@ -3294,7 +3362,7 @@ module Plaid
     end
 
     # List webhook events
-    # &#x60;/beta/webhook_events/list&#x60; returns webhook events for your account from the last 7 days, regardless of delivery outcome. Results are ordered by &#x60;sent_time&#x60;, oldest first, and paginated with a cursor so you can recover deliveries your endpoint missed. Each event includes a &#x60;webhook_message_id&#x60; that stays the same if that event shows up again on a later poll, so you can skip events you have already handled.  &#x60;TRANSACTIONS&#x60; webhooks are not returned. Use [&#x60;/transactions/sync&#x60;](https://plaid.com/docs/api/products/transactions/#transactionssync) to recover transaction updates.  Filtering is optional. For &#x60;webhook_types&#x60;, &#x60;webhook_codes&#x60;, &#x60;item_ids&#x60;, and &#x60;delivery_statuses&#x60;, values within a field match with OR; different fields combine with AND. For example, &#x60;webhook_types: [\&quot;ITEM\&quot;, \&quot;AUTH\&quot;]&#x60; matches events of either type.  To page through events:  - On the first request, omit &#x60;cursor&#x60;. You can set &#x60;start_time&#x60; to a time within the last 7 days, or omit &#x60;start_time&#x60; to start at the oldest retained event. - On later requests, send the previous response&#39;s &#x60;next_cursor&#x60; as &#x60;cursor&#x60;. If you also send &#x60;start_time&#x60;, it is ignored; &#x60;cursor&#x60; takes precedence, even when &#x60;start_time&#x60; has changed. - Save &#x60;next_cursor&#x60; even when &#x60;has_more&#x60; is &#x60;false&#x60;, and send that cursor on the next poll so you only receive events newer than the ones you have already seen.  A request fails with 400 in these cases:  - &#x60;WEBHOOK_EVENTS_START_TIME_OUT_OF_RANGE&#x60; (&#x60;INVALID_INPUT&#x60;) is returned when &#x60;cursor&#x60; is omitted and &#x60;start_time&#x60; is earlier than the 7-day retention window. Retry with a &#x60;start_time&#x60; within the last 7 days, or omit &#x60;start_time&#x60;. - &#x60;WEBHOOK_EVENTS_CURSOR_EXPIRED&#x60; (&#x60;INVALID_INPUT&#x60;) is returned when the cursor is older than the 7-day retention window and can no longer be resolved. Start again with a &#x60;start_time&#x60; within the last 7 days. Events older than that window are no longer available. - &#x60;INVALID_FIELD&#x60; (&#x60;INVALID_REQUEST&#x60;) is returned when &#x60;cursor&#x60; is not a properly formatted string, or when the request is otherwise invalid.  This endpoint is in beta and may change in backwards-incompatible ways before it is generally available. Send feedback or bug reports to building@plaid.com.
+    # &#x60;/beta/webhook_events/list&#x60; returns the webhooks Plaid sent to your account in the last 7 days, including webhooks that weren&#39;t delivered. Use it to recover webhooks your endpoint missed. Events are returned oldest first.  &#x60;TRANSACTIONS&#x60; webhooks are not included. To recover Transactions updates, use [&#x60;/transactions/sync&#x60;](https://plaid.com/docs/api/products/transactions/#transactionssync).  To page through events, omit &#x60;cursor&#x60; on your first request, then pass the previous response&#39;s &#x60;next_cursor&#x60; on each later request. Store &#x60;next_cursor&#x60; even when &#x60;has_more&#x60; is &#x60;false&#x60;, so your next poll returns only newer events.  Filters are optional. An event matches a filter if it matches any of the filter&#39;s values, and must match every filter you provide.  Events older than 7 days are not retained. If your cursor or &#x60;start_time&#x60; is older than that, the request fails with &#x60;WEBHOOK_EVENTS_CURSOR_EXPIRED&#x60; or &#x60;WEBHOOK_EVENTS_START_TIME_OUT_OF_RANGE&#x60;.  This endpoint is in beta and may change in backwards-incompatible ways. Send feedback to building@plaid.com.
     # @param beta_webhook_events_list_request [BetaWebhookEventsListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(BetaWebhookEventsListResponse, Integer, Hash)>] BetaWebhookEventsListResponse data, response status code and response headers
@@ -5255,8 +5323,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Create a CRA Report for provided user
-    # `/cra/report/create` generates a CRA Report for a user from the Items associated with that user.  Each requested product is generated asynchronously. Use the returned `report_id` to retrieve the report once its products are ready.
+    # Generate an updated Consumer Report for your user
+    # `/cra/report/create` generates a Consumer Report for a user. With `scope` set to `PLAID_NETWORK`, the report is generated from the Plaid Network view of the user's profile. With `CLIENT_USER`, the report is generated from only the Items the user linked to your client.  Each requested product is generated asynchronously. Use the returned `report_id` to retrieve the report once its products are ready.
     # @param cra_report_create_request [CraReportCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CraReportCreateResponse]
@@ -5265,8 +5333,8 @@ module Plaid
       data
     end
 
-    # Create a CRA Report for provided user
-    # &#x60;/cra/report/create&#x60; generates a CRA Report for a user from the Items associated with that user.  Each requested product is generated asynchronously. Use the returned &#x60;report_id&#x60; to retrieve the report once its products are ready.
+    # Generate an updated Consumer Report for your user
+    # &#x60;/cra/report/create&#x60; generates a Consumer Report for a user. With &#x60;scope&#x60; set to &#x60;PLAID_NETWORK&#x60;, the report is generated from the Plaid Network view of the user&#39;s profile. With &#x60;CLIENT_USER&#x60;, the report is generated from only the Items the user linked to your client.  Each requested product is generated asynchronously. Use the returned &#x60;report_id&#x60; to retrieve the report once its products are ready.
     # @param cra_report_create_request [CraReportCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CraReportCreateResponse, Integer, Hash)>] CraReportCreateResponse data, response status code and response headers
@@ -5323,8 +5391,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Retrieve a CRA Report for provided user
-    # `/cra/report/get` retrieves a CRA Report for a user.
+    # Retrieve a Consumer Report for your user
+    # `/cra/report/get` retrieves a Consumer Report for a user.
     # @param cra_report_get_request [CraReportGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CraReportGetResponse]
@@ -5333,8 +5401,8 @@ module Plaid
       data
     end
 
-    # Retrieve a CRA Report for provided user
-    # &#x60;/cra/report/get&#x60; retrieves a CRA Report for a user.
+    # Retrieve a Consumer Report for your user
+    # &#x60;/cra/report/get&#x60; retrieves a Consumer Report for a user.
     # @param cra_report_get_request [CraReportGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CraReportGetResponse, Integer, Hash)>] CraReportGetResponse data, response status code and response headers
@@ -6276,7 +6344,7 @@ module Plaid
     end
 
     # Subscribe and unsubscribe to proactive notifications for a user's income profile
-    # `/credit/bank_income/webhook/update` allows you to subscribe or unsubscribe a user for income webhook notifications. By default, all users start out unsubscribed.  If a user is subscribed, on significant changes to the user's income profile, you will receive a `BANK_INCOME_REFRESH_UPDATE` webhook, prompting you to refresh bank income data for the user.
+    # `/credit/bank_income/webhook/update` is deprecated and no longer available; requests return an `INVALID_REQUEST` error with code `NOT_FOUND`.
     # @param credit_bank_income_webhook_update_request [CreditBankIncomeWebhookUpdateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CreditBankIncomeWebhookUpdateResponse]
@@ -6286,7 +6354,7 @@ module Plaid
     end
 
     # Subscribe and unsubscribe to proactive notifications for a user&#39;s income profile
-    # &#x60;/credit/bank_income/webhook/update&#x60; allows you to subscribe or unsubscribe a user for income webhook notifications. By default, all users start out unsubscribed.  If a user is subscribed, on significant changes to the user&#39;s income profile, you will receive a &#x60;BANK_INCOME_REFRESH_UPDATE&#x60; webhook, prompting you to refresh bank income data for the user.
+    # &#x60;/credit/bank_income/webhook/update&#x60; is deprecated and no longer available; requests return an &#x60;INVALID_REQUEST&#x60; error with code &#x60;NOT_FOUND&#x60;.
     # @param credit_bank_income_webhook_update_request [CreditBankIncomeWebhookUpdateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreditBankIncomeWebhookUpdateResponse, Integer, Hash)>] CreditBankIncomeWebhookUpdateResponse data, response status code and response headers
@@ -6684,7 +6752,7 @@ module Plaid
     end
 
     # Check income verification eligibility and optimize conversion
-    # `/credit/payroll_income/precheck` is an optional endpoint that can be called before initializing a Link session for income verification. It evaluates whether a given user is supportable by digital income verification. If the user is eligible for digital verification, that information will be associated with the user token, and in this way will generate a Link UI optimized for the end user and their specific employer. If the user cannot be confirmed as eligible, the user can still use the income verification flow, but they may be required to manually upload a paystub to verify their income.  While all request fields are optional, providing `employer` data will increase the chance of receiving a useful result.  When testing in Sandbox, you can control the results by providing special test values in the `employer` and `access_tokens` fields. `employer_good` and `employer_bad` will result in `HIGH` and `LOW` confidence values, respectively. `employer_multi` will result in a `HIGH` confidence with multiple payroll options. Likewise, `access_good` and `access_bad` will result in `HIGH` and `LOW` confidence values, respectively. Any other value for `employer` and `access_tokens` in Sandbox will result in `UNKNOWN` confidence.
+    # `/credit/payroll_income/precheck` is an optional endpoint that can be called before initializing a Link session for income verification. It evaluates whether a given user is supportable by digital income verification. If the user is eligible for digital verification, that information will be associated with the user token, and in this way will generate a Link UI optimized for the end user and their specific employer. If the user cannot be confirmed as eligible, the user can still use the income verification flow, but they may be required to manually upload a paystub to verify their income.  While all request fields are optional, providing `employer` data will increase the chance of receiving a useful result.  When testing in Sandbox, you can control the results by providing special test values in the `access_tokens` field. `access_good` and `access_bad` will result in `HIGH` and `LOW` confidence values, respectively. Any other valid Sandbox access token will result in `UNKNOWN` confidence; other strings return an `INVALID_ACCESS_TOKEN` error.
     # @param credit_payroll_income_precheck_request [CreditPayrollIncomePrecheckRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CreditPayrollIncomePrecheckResponse]
@@ -6694,7 +6762,7 @@ module Plaid
     end
 
     # Check income verification eligibility and optimize conversion
-    # &#x60;/credit/payroll_income/precheck&#x60; is an optional endpoint that can be called before initializing a Link session for income verification. It evaluates whether a given user is supportable by digital income verification. If the user is eligible for digital verification, that information will be associated with the user token, and in this way will generate a Link UI optimized for the end user and their specific employer. If the user cannot be confirmed as eligible, the user can still use the income verification flow, but they may be required to manually upload a paystub to verify their income.  While all request fields are optional, providing &#x60;employer&#x60; data will increase the chance of receiving a useful result.  When testing in Sandbox, you can control the results by providing special test values in the &#x60;employer&#x60; and &#x60;access_tokens&#x60; fields. &#x60;employer_good&#x60; and &#x60;employer_bad&#x60; will result in &#x60;HIGH&#x60; and &#x60;LOW&#x60; confidence values, respectively. &#x60;employer_multi&#x60; will result in a &#x60;HIGH&#x60; confidence with multiple payroll options. Likewise, &#x60;access_good&#x60; and &#x60;access_bad&#x60; will result in &#x60;HIGH&#x60; and &#x60;LOW&#x60; confidence values, respectively. Any other value for &#x60;employer&#x60; and &#x60;access_tokens&#x60; in Sandbox will result in &#x60;UNKNOWN&#x60; confidence.
+    # &#x60;/credit/payroll_income/precheck&#x60; is an optional endpoint that can be called before initializing a Link session for income verification. It evaluates whether a given user is supportable by digital income verification. If the user is eligible for digital verification, that information will be associated with the user token, and in this way will generate a Link UI optimized for the end user and their specific employer. If the user cannot be confirmed as eligible, the user can still use the income verification flow, but they may be required to manually upload a paystub to verify their income.  While all request fields are optional, providing &#x60;employer&#x60; data will increase the chance of receiving a useful result.  When testing in Sandbox, you can control the results by providing special test values in the &#x60;access_tokens&#x60; field. &#x60;access_good&#x60; and &#x60;access_bad&#x60; will result in &#x60;HIGH&#x60; and &#x60;LOW&#x60; confidence values, respectively. Any other valid Sandbox access token will result in &#x60;UNKNOWN&#x60; confidence; other strings return an &#x60;INVALID_ACCESS_TOKEN&#x60; error.
     # @param credit_payroll_income_precheck_request [CreditPayrollIncomePrecheckRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreditPayrollIncomePrecheckResponse, Integer, Hash)>] CreditPayrollIncomePrecheckResponse data, response status code and response headers
@@ -8298,7 +8366,7 @@ module Plaid
     end
 
     # List Link Identity Match attempts
-    # Returns a chronological history of Link-originated Identity Match attempts for a client, ordered by creation time with the oldest attempt first.  Results are retained for up to one year. Attempts for deleted Items are omitted.
+    # Returns a chronological history of Link-originated Identity Match attempts for a client, ordered by creation time with the oldest attempt first.  This endpoint requires separate enablement in addition to access to Identity Match. To request endpoint access, contact your account manager or [submit a product access support ticket](https://dashboard.plaid.com/support/new/product-and-development/product-troubleshooting/request-product-access).  Results are retained for up to one year. Attempts marked as deleted are omitted.
     # @param identity_match_list_request [IdentityMatchListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [IdentityMatchListResponse]
@@ -8308,7 +8376,7 @@ module Plaid
     end
 
     # List Link Identity Match attempts
-    # Returns a chronological history of Link-originated Identity Match attempts for a client, ordered by creation time with the oldest attempt first.  Results are retained for up to one year. Attempts for deleted Items are omitted.
+    # Returns a chronological history of Link-originated Identity Match attempts for a client, ordered by creation time with the oldest attempt first.  This endpoint requires separate enablement in addition to access to Identity Match. To request endpoint access, contact your account manager or [submit a product access support ticket](https://dashboard.plaid.com/support/new/product-and-development/product-troubleshooting/request-product-access).  Results are retained for up to one year. Attempts marked as deleted are omitted.
     # @param identity_match_list_request [IdentityMatchListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(IdentityMatchListResponse, Integer, Hash)>] IdentityMatchListResponse data, response status code and response headers
@@ -9454,7 +9522,7 @@ module Plaid
     end
 
     # Refresh investment data
-    # `/investments/refresh` is an optional endpoint for users of the Investments product. It initiates an on-demand extraction to fetch the newest investment holdings and transactions for an Item. This on-demand extraction takes place in addition to the periodic extractions that automatically occur one or more times per day for any Investments-enabled Item. If changes to investments are discovered after calling `/investments/refresh`, Plaid will fire webhooks: [`HOLDINGS: DEFAULT_UPDATE`](https://plaid.com/docs/api/products/investments/#holdings-default_update) if any new holdings are detected, and [`INVESTMENTS_TRANSACTIONS: DEFAULT_UPDATE`](https://plaid.com/docs/api/products/investments/#investments_transactions-default_update) if any new investment transactions are detected. This webhook will typically not fire in the Sandbox environment, due to the lack of dynamic investment transactions and holdings data. To test this webhook in Sandbox, call `/sandbox/item/fire_webhook`. Updated holdings and investment transactions can be fetched by calling `/investments/holdings/get` and `/investments/transactions/get`. Note that the `/investments/refresh` endpoint is not supported by all institutions. If called on an Item from an institution that does not support this functionality, it will return a `PRODUCT_NOT_SUPPORTED` error.  As this endpoint triggers a synchronous request for fresh data, latency may be higher than for other Plaid endpoints (typically less than 10 seconds, but occasionally up to 30 seconds or more); if you encounter errors, you may find it necessary to adjust your timeout period when making requests.  `/investments/refresh` is offered as an add-on to Investments and has a separate [fee model](https://plaid.com/docs/account/billing/#per-request-flat-fee). To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.
+    # `/investments/refresh` is an optional endpoint for users of the Investments product. It initiates an on-demand extraction to fetch the newest investment holdings and transactions for an Item. This on-demand extraction takes place in addition to the periodic extractions that automatically occur one or more times per day for any Investments-enabled Item. If changes to investments are discovered after calling `/investments/refresh`, Plaid will fire webhooks: [`HOLDINGS: DEFAULT_UPDATE`](https://plaid.com/docs/api/products/investments/#holdings-default_update) if any new holdings are detected, and [`INVESTMENTS_TRANSACTIONS: DEFAULT_UPDATE`](https://plaid.com/docs/api/products/investments/#investments_transactions-default_update) if any new investment transactions are detected. This webhook will typically not fire in the Sandbox environment, due to the lack of dynamic investment transactions and holdings data. To test this webhook in Sandbox, call `/sandbox/item/fire_webhook`. Updated holdings and investment transactions can be fetched by calling `/investments/holdings/get` and `/investments/transactions/get`. Note that the `/investments/refresh` endpoint is not supported by all institutions. If called on an Item from an institution that does not support this functionality, it will return a `PRODUCTS_NOT_SUPPORTED` error.  As this endpoint triggers a synchronous request for fresh data, latency may be higher than for other Plaid endpoints (typically less than 10 seconds, but occasionally up to 30 seconds or more); if you encounter errors, you may find it necessary to adjust your timeout period when making requests.  `/investments/refresh` is offered as an add-on to Investments and has a separate [fee model](https://plaid.com/docs/account/billing/#per-request-flat-fee). To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.
     # @param investments_refresh_request [InvestmentsRefreshRequest] 
     # @param [Hash] opts the optional parameters
     # @return [InvestmentsRefreshResponse]
@@ -9464,7 +9532,7 @@ module Plaid
     end
 
     # Refresh investment data
-    # &#x60;/investments/refresh&#x60; is an optional endpoint for users of the Investments product. It initiates an on-demand extraction to fetch the newest investment holdings and transactions for an Item. This on-demand extraction takes place in addition to the periodic extractions that automatically occur one or more times per day for any Investments-enabled Item. If changes to investments are discovered after calling &#x60;/investments/refresh&#x60;, Plaid will fire webhooks: [&#x60;HOLDINGS: DEFAULT_UPDATE&#x60;](https://plaid.com/docs/api/products/investments/#holdings-default_update) if any new holdings are detected, and [&#x60;INVESTMENTS_TRANSACTIONS: DEFAULT_UPDATE&#x60;](https://plaid.com/docs/api/products/investments/#investments_transactions-default_update) if any new investment transactions are detected. This webhook will typically not fire in the Sandbox environment, due to the lack of dynamic investment transactions and holdings data. To test this webhook in Sandbox, call &#x60;/sandbox/item/fire_webhook&#x60;. Updated holdings and investment transactions can be fetched by calling &#x60;/investments/holdings/get&#x60; and &#x60;/investments/transactions/get&#x60;. Note that the &#x60;/investments/refresh&#x60; endpoint is not supported by all institutions. If called on an Item from an institution that does not support this functionality, it will return a &#x60;PRODUCT_NOT_SUPPORTED&#x60; error.  As this endpoint triggers a synchronous request for fresh data, latency may be higher than for other Plaid endpoints (typically less than 10 seconds, but occasionally up to 30 seconds or more); if you encounter errors, you may find it necessary to adjust your timeout period when making requests.  &#x60;/investments/refresh&#x60; is offered as an add-on to Investments and has a separate [fee model](https://plaid.com/docs/account/billing/#per-request-flat-fee). To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.
+    # &#x60;/investments/refresh&#x60; is an optional endpoint for users of the Investments product. It initiates an on-demand extraction to fetch the newest investment holdings and transactions for an Item. This on-demand extraction takes place in addition to the periodic extractions that automatically occur one or more times per day for any Investments-enabled Item. If changes to investments are discovered after calling &#x60;/investments/refresh&#x60;, Plaid will fire webhooks: [&#x60;HOLDINGS: DEFAULT_UPDATE&#x60;](https://plaid.com/docs/api/products/investments/#holdings-default_update) if any new holdings are detected, and [&#x60;INVESTMENTS_TRANSACTIONS: DEFAULT_UPDATE&#x60;](https://plaid.com/docs/api/products/investments/#investments_transactions-default_update) if any new investment transactions are detected. This webhook will typically not fire in the Sandbox environment, due to the lack of dynamic investment transactions and holdings data. To test this webhook in Sandbox, call &#x60;/sandbox/item/fire_webhook&#x60;. Updated holdings and investment transactions can be fetched by calling &#x60;/investments/holdings/get&#x60; and &#x60;/investments/transactions/get&#x60;. Note that the &#x60;/investments/refresh&#x60; endpoint is not supported by all institutions. If called on an Item from an institution that does not support this functionality, it will return a &#x60;PRODUCTS_NOT_SUPPORTED&#x60; error.  As this endpoint triggers a synchronous request for fresh data, latency may be higher than for other Plaid endpoints (typically less than 10 seconds, but occasionally up to 30 seconds or more); if you encounter errors, you may find it necessary to adjust your timeout period when making requests.  &#x60;/investments/refresh&#x60; is offered as an add-on to Investments and has a separate [fee model](https://plaid.com/docs/account/billing/#per-request-flat-fee). To request access to this endpoint, submit a [product access request](https://dashboard.plaid.com/team/products) or contact your Plaid account manager.
     # @param investments_refresh_request [InvestmentsRefreshRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(InvestmentsRefreshResponse, Integer, Hash)>] InvestmentsRefreshResponse data, response status code and response headers
@@ -9658,7 +9726,7 @@ module Plaid
     end
 
     # Search for an Issue
-    # Search for an issue associated with one of the following identifiers:  `item_id`, `link_session_id` or Link session `request_id`. This endpoint returns a list of `Issue` objects, with an empty list indicating that no issues are associated with the provided identifier. At least one of the identifiers must be provided to perform the search.
+    # Search for an issue associated with one of the following identifiers:  `item_id`, `link_session_id` or Link session `request_id`. This endpoint returns a list containing at most one issue. If no issues are associated with the provided identifier, `issues` is omitted. At least one of the identifiers must be provided to perform the search.
     # @param issues_search_request [IssuesSearchRequest] 
     # @param [Hash] opts the optional parameters
     # @return [IssuesSearchResponse]
@@ -9668,7 +9736,7 @@ module Plaid
     end
 
     # Search for an Issue
-    # Search for an issue associated with one of the following identifiers:  &#x60;item_id&#x60;, &#x60;link_session_id&#x60; or Link session &#x60;request_id&#x60;. This endpoint returns a list of &#x60;Issue&#x60; objects, with an empty list indicating that no issues are associated with the provided identifier. At least one of the identifiers must be provided to perform the search.
+    # Search for an issue associated with one of the following identifiers:  &#x60;item_id&#x60;, &#x60;link_session_id&#x60; or Link session &#x60;request_id&#x60;. This endpoint returns a list containing at most one issue. If no issues are associated with the provided identifier, &#x60;issues&#x60; is omitted. At least one of the identifiers must be provided to perform the search.
     # @param issues_search_request [IssuesSearchRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(IssuesSearchResponse, Integer, Hash)>] IssuesSearchResponse data, response status code and response headers
@@ -10610,7 +10678,7 @@ module Plaid
     end
 
     # Retrieve Liabilities data
-    # The `/liabilities/get` endpoint returns various details about an Item with loan or credit accounts. Liabilities data is available primarily for US financial institutions, with some limited coverage of Canadian institutions. Currently supported account types are account type `credit` with account subtype `credit card` or `paypal`, and account type `loan` with account subtype `student` or `mortgage`. To limit accounts listed in Link to types and subtypes supported by Liabilities, you can use the `account_filters` parameter when [creating a Link token](https://plaid.com/docs/api/link/#linktokencreate).  The types of information returned by Liabilities can include balances and due dates, loan terms, and account details such as original loan amount and guarantor. Data is refreshed approximately once per day; the latest data can be retrieved by calling `/liabilities/get`.
+    # The `/liabilities/get` endpoint returns various details about an Item with loan or credit accounts. Liabilities data is available primarily for US financial institutions, with some limited coverage of Canadian institutions. Supported account types are account type `credit` with account subtype `credit card` or `paypal`; and account type `loan` with account subtype `auto`, `commercial`, `commercial line of credit`, `consumer`, `home equity`, `home equity loan`, `line of credit`, `loan`, `mortgage`, or `student`. To limit accounts listed in Link to types and subtypes supported by Liabilities, you can use the `account_filters` parameter when [creating a Link token](https://plaid.com/docs/api/link/#linktokencreate).  To receive the expanded loan subtype values, use plaid-go 10.1.0 or later, plaid-java 44.0.0 or later, plaid-python 8.3.0 or later, or plaid-ruby 14.4.0 or later. Earlier client library versions may receive `loan` instead of `home equity loan` and `line of credit` instead of `commercial line of credit`.  The types of information returned by Liabilities can include balances and due dates, loan terms, and account details such as original loan amount and guarantor. Data is refreshed approximately once per day; the latest data can be retrieved by calling `/liabilities/get`.
     # @param liabilities_get_request [LiabilitiesGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [LiabilitiesGetResponse]
@@ -10620,7 +10688,7 @@ module Plaid
     end
 
     # Retrieve Liabilities data
-    # The &#x60;/liabilities/get&#x60; endpoint returns various details about an Item with loan or credit accounts. Liabilities data is available primarily for US financial institutions, with some limited coverage of Canadian institutions. Currently supported account types are account type &#x60;credit&#x60; with account subtype &#x60;credit card&#x60; or &#x60;paypal&#x60;, and account type &#x60;loan&#x60; with account subtype &#x60;student&#x60; or &#x60;mortgage&#x60;. To limit accounts listed in Link to types and subtypes supported by Liabilities, you can use the &#x60;account_filters&#x60; parameter when [creating a Link token](https://plaid.com/docs/api/link/#linktokencreate).  The types of information returned by Liabilities can include balances and due dates, loan terms, and account details such as original loan amount and guarantor. Data is refreshed approximately once per day; the latest data can be retrieved by calling &#x60;/liabilities/get&#x60;.
+    # The &#x60;/liabilities/get&#x60; endpoint returns various details about an Item with loan or credit accounts. Liabilities data is available primarily for US financial institutions, with some limited coverage of Canadian institutions. Supported account types are account type &#x60;credit&#x60; with account subtype &#x60;credit card&#x60; or &#x60;paypal&#x60;; and account type &#x60;loan&#x60; with account subtype &#x60;auto&#x60;, &#x60;commercial&#x60;, &#x60;commercial line of credit&#x60;, &#x60;consumer&#x60;, &#x60;home equity&#x60;, &#x60;home equity loan&#x60;, &#x60;line of credit&#x60;, &#x60;loan&#x60;, &#x60;mortgage&#x60;, or &#x60;student&#x60;. To limit accounts listed in Link to types and subtypes supported by Liabilities, you can use the &#x60;account_filters&#x60; parameter when [creating a Link token](https://plaid.com/docs/api/link/#linktokencreate).  To receive the expanded loan subtype values, use plaid-go 10.1.0 or later, plaid-java 44.0.0 or later, plaid-python 8.3.0 or later, or plaid-ruby 14.4.0 or later. Earlier client library versions may receive &#x60;loan&#x60; instead of &#x60;home equity loan&#x60; and &#x60;line of credit&#x60; instead of &#x60;commercial line of credit&#x60;.  The types of information returned by Liabilities can include balances and due dates, loan terms, and account details such as original loan amount and guarantor. Data is refreshed approximately once per day; the latest data can be retrieved by calling &#x60;/liabilities/get&#x60;.
     # @param liabilities_get_request [LiabilitiesGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(LiabilitiesGetResponse, Integer, Hash)>] LiabilitiesGetResponse data, response status code and response headers
@@ -11834,7 +11902,7 @@ module Plaid
     end
 
     # Get payment details
-    # The `/payment_initiation/payment/get` endpoint can be used to check the status of a payment, as well as to receive basic information such as recipient and payment amount. In the case of standing orders, the `/payment_initiation/payment/get` endpoint will provide information about the status of the overall standing order itself; the API cannot be used to retrieve payment status for individual payments within a standing order.  Polling for status updates in Production is highly discouraged. Repeatedly calling `/payment_initiation/payment/get` to check a payment's status is unreliable and may trigger API rate limits. Only the `payment_status_update` webhook should be used to receive real-time status updates in Production.
+    # The `/payment_initiation/payment/get` endpoint can be used to check the status of a payment, as well as to receive basic information such as recipient and payment amount. In the case of standing orders, the `/payment_initiation/payment/get` endpoint will provide information about the status of the overall standing order itself; the API cannot be used to retrieve payment status for individual payments within a standing order.  Polling for status updates in Production is highly discouraged. Repeatedly calling `/payment_initiation/payment/get` to check a payment's status is unreliable and may trigger API rate limits. Only the `PAYMENT_STATUS_UPDATE` webhook should be used to receive real-time status updates in Production.
     # @param payment_initiation_payment_get_request [PaymentInitiationPaymentGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [PaymentInitiationPaymentGetResponse]
@@ -11844,7 +11912,7 @@ module Plaid
     end
 
     # Get payment details
-    # The &#x60;/payment_initiation/payment/get&#x60; endpoint can be used to check the status of a payment, as well as to receive basic information such as recipient and payment amount. In the case of standing orders, the &#x60;/payment_initiation/payment/get&#x60; endpoint will provide information about the status of the overall standing order itself; the API cannot be used to retrieve payment status for individual payments within a standing order.  Polling for status updates in Production is highly discouraged. Repeatedly calling &#x60;/payment_initiation/payment/get&#x60; to check a payment&#39;s status is unreliable and may trigger API rate limits. Only the &#x60;payment_status_update&#x60; webhook should be used to receive real-time status updates in Production.
+    # The &#x60;/payment_initiation/payment/get&#x60; endpoint can be used to check the status of a payment, as well as to receive basic information such as recipient and payment amount. In the case of standing orders, the &#x60;/payment_initiation/payment/get&#x60; endpoint will provide information about the status of the overall standing order itself; the API cannot be used to retrieve payment status for individual payments within a standing order.  Polling for status updates in Production is highly discouraged. Repeatedly calling &#x60;/payment_initiation/payment/get&#x60; to check a payment&#39;s status is unreliable and may trigger API rate limits. Only the &#x60;PAYMENT_STATUS_UPDATE&#x60; webhook should be used to receive real-time status updates in Production.
     # @param payment_initiation_payment_get_request [PaymentInitiationPaymentGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(PaymentInitiationPaymentGetResponse, Integer, Hash)>] PaymentInitiationPaymentGetResponse data, response status code and response headers
@@ -12650,7 +12718,7 @@ module Plaid
     end
 
     # Retrieve Balance data
-    # The `/processor/balance/get` endpoint returns the real-time balance for each of an Item's accounts. While other endpoints may return a balance object, only `/processor/balance/get` forces the available and current balance fields to be refreshed rather than cached. 
+    # The `/processor/balance/get` endpoint returns the real-time balance for the account associated with the processor token. While other endpoints may return a balance object, only `/processor/balance/get` forces the available and current balance fields to be refreshed rather than cached. 
     # @param processor_balance_get_request [ProcessorBalanceGetRequest] The &#x60;/processor/balance/get&#x60; endpoint returns the real-time balance for the account associated with a given &#x60;processor_token&#x60;.  The current balance is the total amount of funds in the account. The available balance is the current balance less any outstanding holds or debits that have not yet posted to the account.  Note that not all institutions calculate the available balance. In the event that available balance is unavailable from the institution, Plaid will return an available balance value of &#x60;null&#x60;.
     # @param [Hash] opts the optional parameters
     # @return [ProcessorBalanceGetResponse]
@@ -12660,7 +12728,7 @@ module Plaid
     end
 
     # Retrieve Balance data
-    # The &#x60;/processor/balance/get&#x60; endpoint returns the real-time balance for each of an Item&#39;s accounts. While other endpoints may return a balance object, only &#x60;/processor/balance/get&#x60; forces the available and current balance fields to be refreshed rather than cached. 
+    # The &#x60;/processor/balance/get&#x60; endpoint returns the real-time balance for the account associated with the processor token. While other endpoints may return a balance object, only &#x60;/processor/balance/get&#x60; forces the available and current balance fields to be refreshed rather than cached. 
     # @param processor_balance_get_request [ProcessorBalanceGetRequest] The &#x60;/processor/balance/get&#x60; endpoint returns the real-time balance for the account associated with a given &#x60;processor_token&#x60;.  The current balance is the total amount of funds in the account. The available balance is the current balance less any outstanding holds or debits that have not yet posted to the account.  Note that not all institutions calculate the available balance. In the event that available balance is unavailable from the institution, Plaid will return an available balance value of &#x60;null&#x60;.
     # @param [Hash] opts the optional parameters
     # @return [Array<(ProcessorBalanceGetResponse, Integer, Hash)>] ProcessorBalanceGetResponse data, response status code and response headers
@@ -13806,7 +13874,7 @@ module Plaid
     end
 
     # Get transaction data
-    # The `/processor/transactions/get` endpoint allows developers to receive user-authorized transaction data for credit, depository, and some loan-type accounts (only those with account subtype `student` or `mortgage`; coverage may be limited). Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available.  Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in `/processor/transactions/get`.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions).  Due to the potentially large number of transactions associated with a processor token, results are paginated. Manipulate the `count` and `offset` parameters in conjunction with the `total_transactions` response body field to fetch all available transactions.  Data returned by `/processor/transactions/get` will be the data available for the processor token as of the most recent successful check for new transactions. 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. To force Plaid to check for new transactions, you can use the `/processor/transactions/refresh` endpoint.  Note that data may not be immediately available to `/processor/transactions/get`. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with `transactions`, or upon the first call to `/processor/transactions/get`, if it wasn't. If no transaction history is ready when `/processor/transactions/get` is called, it will return a `PRODUCT_NOT_READY` error.  To receive Transactions webhooks for a processor token, set its webhook URL via the [`/processor/token/webhook/update`](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
+    # The `/processor/transactions/get` endpoint allows developers to receive user-authorized transaction data for credit, depository, and loan-type accounts (coverage may be limited). Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available.  Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in `/processor/transactions/get`.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions).  Due to the potentially large number of transactions associated with a processor token, results are paginated. Manipulate the `count` and `offset` parameters in conjunction with the `total_transactions` response body field to fetch all available transactions.  Data returned by `/processor/transactions/get` will be the data available for the processor token as of the most recent successful check for new transactions. 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. To force Plaid to check for new transactions, you can use the `/processor/transactions/refresh` endpoint.  Note that data may not be immediately available to `/processor/transactions/get`. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with `transactions`, or upon the first call to `/processor/transactions/get`, if it wasn't. If no transaction history is ready when `/processor/transactions/get` is called, it will return a `PRODUCT_NOT_READY` error.  To receive Transactions webhooks for a processor token, set its webhook URL via the [`/processor/token/webhook/update`](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
     # @param processor_transactions_get_request [ProcessorTransactionsGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [ProcessorTransactionsGetResponse]
@@ -13816,7 +13884,7 @@ module Plaid
     end
 
     # Get transaction data
-    # The &#x60;/processor/transactions/get&#x60; endpoint allows developers to receive user-authorized transaction data for credit, depository, and some loan-type accounts (only those with account subtype &#x60;student&#x60; or &#x60;mortgage&#x60;; coverage may be limited). Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available.  Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in &#x60;/processor/transactions/get&#x60;.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions).  Due to the potentially large number of transactions associated with a processor token, results are paginated. Manipulate the &#x60;count&#x60; and &#x60;offset&#x60; parameters in conjunction with the &#x60;total_transactions&#x60; response body field to fetch all available transactions.  Data returned by &#x60;/processor/transactions/get&#x60; will be the data available for the processor token as of the most recent successful check for new transactions. 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. To force Plaid to check for new transactions, you can use the &#x60;/processor/transactions/refresh&#x60; endpoint.  Note that data may not be immediately available to &#x60;/processor/transactions/get&#x60;. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with &#x60;transactions&#x60;, or upon the first call to &#x60;/processor/transactions/get&#x60;, if it wasn&#39;t. If no transaction history is ready when &#x60;/processor/transactions/get&#x60; is called, it will return a &#x60;PRODUCT_NOT_READY&#x60; error.  To receive Transactions webhooks for a processor token, set its webhook URL via the [&#x60;/processor/token/webhook/update&#x60;](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
+    # The &#x60;/processor/transactions/get&#x60; endpoint allows developers to receive user-authorized transaction data for credit, depository, and loan-type accounts (coverage may be limited). Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available.  Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in &#x60;/processor/transactions/get&#x60;.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions).  Due to the potentially large number of transactions associated with a processor token, results are paginated. Manipulate the &#x60;count&#x60; and &#x60;offset&#x60; parameters in conjunction with the &#x60;total_transactions&#x60; response body field to fetch all available transactions.  Data returned by &#x60;/processor/transactions/get&#x60; will be the data available for the processor token as of the most recent successful check for new transactions. 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. To force Plaid to check for new transactions, you can use the &#x60;/processor/transactions/refresh&#x60; endpoint.  Note that data may not be immediately available to &#x60;/processor/transactions/get&#x60;. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with &#x60;transactions&#x60;, or upon the first call to &#x60;/processor/transactions/get&#x60;, if it wasn&#39;t. If no transaction history is ready when &#x60;/processor/transactions/get&#x60; is called, it will return a &#x60;PRODUCT_NOT_READY&#x60; error.  To receive Transactions webhooks for a processor token, set its webhook URL via the [&#x60;/processor/token/webhook/update&#x60;](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
     # @param processor_transactions_get_request [ProcessorTransactionsGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(ProcessorTransactionsGetResponse, Integer, Hash)>] ProcessorTransactionsGetResponse data, response status code and response headers
@@ -14010,7 +14078,7 @@ module Plaid
     end
 
     # Get incremental transaction updates on a processor token
-    #  The `/processor/transactions/sync` endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with `/processor/transactions/sync`, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using `/processor/transactions/get`, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports `credit`, `depository`, and some `loan`-type accounts (only those with account subtype `student` or `mortgage`). For `investments` accounts, use `/investments/transactions/get` instead.  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 `/processor/transactions/sync` fails when retrieving a paginated update (e.g. due to the [`TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION`](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the `/link/token/create` call or if `/processor/transactions/sync` was called within a few seconds of Item creation, `/processor/transactions/sync` will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call `/item/get`; the `item.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 `/processor/transactions/refresh` endpoint.  To be alerted when new transactions are available, listen for the [`SYNC_UPDATES_AVAILABLE`](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.  To receive Transactions webhooks for a processor token, set its webhook URL via the [`/processor/token/webhook/update`](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
+    #  The `/processor/transactions/sync` endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with `/processor/transactions/sync`, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using `/processor/transactions/get`, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports `credit`, `depository`, and `loan`-type accounts. For `investments` accounts, use `/processor/investments/transactions/get` instead.  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 `/processor/transactions/sync` fails when retrieving a paginated update (e.g. due to the [`TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION`](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the `/link/token/create` call or if `/processor/transactions/sync` was called within a few seconds of Item creation, `/processor/transactions/sync` will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call `/item/get`; the `item.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 `/processor/transactions/refresh` endpoint.  To be alerted when new transactions are available, listen for the [`SYNC_UPDATES_AVAILABLE`](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.  To receive Transactions webhooks for a processor token, set its webhook URL via the [`/processor/token/webhook/update`](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
     # @param processor_transactions_sync_request [ProcessorTransactionsSyncRequest] 
     # @param [Hash] opts the optional parameters
     # @return [ProcessorTransactionsSyncResponse]
@@ -14020,7 +14088,7 @@ module Plaid
     end
 
     # Get incremental transaction updates on a processor token
-    #  The &#x60;/processor/transactions/sync&#x60; endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with &#x60;/processor/transactions/sync&#x60;, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using &#x60;/processor/transactions/get&#x60;, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports &#x60;credit&#x60;, &#x60;depository&#x60;, and some &#x60;loan&#x60;-type accounts (only those with account subtype &#x60;student&#x60; or &#x60;mortgage&#x60;). For &#x60;investments&#x60; accounts, use &#x60;/investments/transactions/get&#x60; instead.  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;/processor/transactions/sync&#x60; fails when retrieving a paginated update (e.g. due to the [&#x60;TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION&#x60;](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the &#x60;/link/token/create&#x60; call or if &#x60;/processor/transactions/sync&#x60; was called within a few seconds of Item creation, &#x60;/processor/transactions/sync&#x60; will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call &#x60;/item/get&#x60;; the &#x60;item.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;/processor/transactions/refresh&#x60; endpoint.  To be alerted when new transactions are available, listen for the [&#x60;SYNC_UPDATES_AVAILABLE&#x60;](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.  To receive Transactions webhooks for a processor token, set its webhook URL via the [&#x60;/processor/token/webhook/update&#x60;](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
+    #  The &#x60;/processor/transactions/sync&#x60; endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with &#x60;/processor/transactions/sync&#x60;, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using &#x60;/processor/transactions/get&#x60;, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports &#x60;credit&#x60;, &#x60;depository&#x60;, and &#x60;loan&#x60;-type accounts. For &#x60;investments&#x60; accounts, use &#x60;/processor/investments/transactions/get&#x60; instead.  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;/processor/transactions/sync&#x60; fails when retrieving a paginated update (e.g. due to the [&#x60;TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION&#x60;](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the &#x60;/link/token/create&#x60; call or if &#x60;/processor/transactions/sync&#x60; was called within a few seconds of Item creation, &#x60;/processor/transactions/sync&#x60; will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call &#x60;/item/get&#x60;; the &#x60;item.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;/processor/transactions/refresh&#x60; endpoint.  To be alerted when new transactions are available, listen for the [&#x60;SYNC_UPDATES_AVAILABLE&#x60;](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.  To receive Transactions webhooks for a processor token, set its webhook URL via the [&#x60;/processor/token/webhook/update&#x60;](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
     # @param processor_transactions_sync_request [ProcessorTransactionsSyncRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(ProcessorTransactionsSyncResponse, Integer, Hash)>] ProcessorTransactionsSyncResponse data, response status code and response headers
@@ -14350,7 +14418,7 @@ module Plaid
     end
 
     # Compute Protect Trust Index scores and subscores
-    # Compute a Protect Trust Index score for a user. The model selected determines what is scored and what additional fields the response contains. For example, `ti-link-session-3-<client>` scores a completed Link session for fraud risk; `cash-advance-onboarding-<client>-1.0` scores repayment risk for a first-time cash advance and `cash-advance-ongoing-<client>-1.0` scores subsequent advances, both additionally populating per-amount-bucket subscores. Cash-advance models require that the user have a Plaid Item with Transactions enabled, or an Assets Report, before scoring.  The endpoint returns HTTP 400 with `error_type` = `INVALID_REQUEST` and `error_code` = `FAILED_PRECONDITION` when a required precondition is not met: for link-session models, when the Link session has not completed; for cash-advance models, when the user has not successfully linked any Item.
+    # Compute a Protect Trust Index score for a user. The model selected determines what is scored and what additional fields the response contains. For example, `ti-link-session-3-<client>` scores a completed Link session for fraud risk; `cash-advance-ongoing-<client>-1.0` scores repayment risk for a cash advance, additionally populating per-amount-bucket subscores. Cash-advance models require that the user have a Plaid Item with Transactions enabled, or an Assets Report, before scoring.  The endpoint returns HTTP 400 with `error_type` = `INVALID_REQUEST` and `error_code` = `FAILED_PRECONDITION` when a required precondition is not met: for link-session models, when the Link session has not completed; for cash-advance models, when the user has not successfully linked any Item. For device-session models, the endpoint may return retryable `error_code` = `SESSION_NOT_READY` until the Protect SDK has delivered device data for the session.
     # @param protect_compute_request [ProtectComputeRequest] 
     # @param [Hash] opts the optional parameters
     # @return [ProtectComputeResponse]
@@ -14360,7 +14428,7 @@ module Plaid
     end
 
     # Compute Protect Trust Index scores and subscores
-    # Compute a Protect Trust Index score for a user. The model selected determines what is scored and what additional fields the response contains. For example, &#x60;ti-link-session-3-&lt;client&gt;&#x60; scores a completed Link session for fraud risk; &#x60;cash-advance-onboarding-&lt;client&gt;-1.0&#x60; scores repayment risk for a first-time cash advance and &#x60;cash-advance-ongoing-&lt;client&gt;-1.0&#x60; scores subsequent advances, both additionally populating per-amount-bucket subscores. Cash-advance models require that the user have a Plaid Item with Transactions enabled, or an Assets Report, before scoring.  The endpoint returns HTTP 400 with &#x60;error_type&#x60; &#x3D; &#x60;INVALID_REQUEST&#x60; and &#x60;error_code&#x60; &#x3D; &#x60;FAILED_PRECONDITION&#x60; when a required precondition is not met: for link-session models, when the Link session has not completed; for cash-advance models, when the user has not successfully linked any Item.
+    # Compute a Protect Trust Index score for a user. The model selected determines what is scored and what additional fields the response contains. For example, &#x60;ti-link-session-3-&lt;client&gt;&#x60; scores a completed Link session for fraud risk; &#x60;cash-advance-ongoing-&lt;client&gt;-1.0&#x60; scores repayment risk for a cash advance, additionally populating per-amount-bucket subscores. Cash-advance models require that the user have a Plaid Item with Transactions enabled, or an Assets Report, before scoring.  The endpoint returns HTTP 400 with &#x60;error_type&#x60; &#x3D; &#x60;INVALID_REQUEST&#x60; and &#x60;error_code&#x60; &#x3D; &#x60;FAILED_PRECONDITION&#x60; when a required precondition is not met: for link-session models, when the Link session has not completed; for cash-advance models, when the user has not successfully linked any Item. For device-session models, the endpoint may return retryable &#x60;error_code&#x60; &#x3D; &#x60;SESSION_NOT_READY&#x60; until the Protect SDK has delivered device data for the session.
     # @param protect_compute_request [ProtectComputeRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(ProtectComputeResponse, Integer, Hash)>] ProtectComputeResponse data, response status code and response headers
@@ -15234,7 +15302,7 @@ module Plaid
     end
 
     # Fire a test webhook
-    # The `/sandbox/item/fire_webhook` endpoint is used to test that code correctly handles webhooks. This endpoint can trigger the following webhooks:  `DEFAULT_UPDATE`: Webhook to be fired for a given Sandbox Item simulating a default update event for the respective product as specified with the `webhook_type` in the request body. Valid Sandbox `DEFAULT_UPDATE` webhook types include: `AUTH`, `IDENTITY`, `TRANSACTIONS`, `INVESTMENTS_TRANSACTIONS`, `LIABILITIES`, `HOLDINGS`. If the Item does not support the product, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `NEW_ACCOUNTS_AVAILABLE`: Fired to indicate that a new account is available on the Item and you can launch update mode to request access to it.  `SMS_MICRODEPOSITS_VERIFICATION`: Fired when a given Same-Day Micro-deposit Item is verified via SMS verification.  `LOGIN_REPAIRED`: Fired when an Item recovers from the `ITEM_LOGIN_REQUIRED` without the user going through update mode in your app.  `PENDING_DISCONNECT`: Fired when an Item will stop working in the near future (e.g. due to a planned bank migration) and must be sent through update mode to continue working.  `RECURRING_TRANSACTIONS_UPDATE`: Recurring Transactions webhook to be fired for a given Sandbox Item. If the Item does not support Recurring Transactions, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `SYNC_UPDATES_AVAILABLE`: Transactions webhook to be fired for a given Sandbox Item.  If the Item does not support Transactions, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `PRODUCT_READY`: Assets webhook to be fired when a given asset report has been successfully generated. If the Item does not support Assets, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `ERROR`: Assets webhook to be fired when asset report generation has failed. If the Item does not support Assets, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `USER_PERMISSION_REVOKED`: Indicates an end user has revoked the permission that they previously granted to access an Item. May not always fire upon revocation, as some institutions' consent portals do not trigger this webhook. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  `USER_ACCOUNT_REVOKED`: Fired when an end user has revoked access to their account on the Data Provider's portal. This webhook is currently sent only for Chase, PNC, and Truist Items, but may be sent in the future for other financial institutions. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  Note that this endpoint is provided for developer ease-of-use and is not required for testing webhooks; webhooks will also fire in Sandbox under the same conditions that they would in Production (except for webhooks of type `TRANSFER`).
+    # The `/sandbox/item/fire_webhook` endpoint is used to test that code correctly handles webhooks. This endpoint can trigger the following webhooks:  `DEFAULT_UPDATE`: Webhook to be fired for a given Sandbox Item simulating a default update event for the respective product as specified with the `webhook_type` in the request body. Valid Sandbox `DEFAULT_UPDATE` webhook types include: `AUTH`, `IDENTITY`, `TRANSACTIONS`, `INVESTMENTS_TRANSACTIONS`, `LIABILITIES`, `HOLDINGS`. If the Item does not support the product, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `NEW_ACCOUNTS_AVAILABLE`: Fired to indicate that a new account is available on the Item and you can launch update mode to request access to it.  `SMS_MICRODEPOSITS_VERIFICATION`: Fired when a given Same-Day Micro-deposit Item is verified via SMS verification.  `LOGIN_REPAIRED`: Fired when an Item recovers from the `ITEM_LOGIN_REQUIRED` without the user going through update mode in your app.  `PENDING_DISCONNECT`: Fired when an Item will stop working in the near future (e.g. due to a planned bank migration) and must be sent through update mode to continue working.  `RECURRING_TRANSACTIONS_UPDATE`: Recurring Transactions webhook to be fired for a given Sandbox Item. If your client is not enabled for Recurring Transactions, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `SYNC_UPDATES_AVAILABLE`: Transactions webhook to be fired for a given Sandbox Item.  If your client is not enabled for Transactions, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `PRODUCT_READY`: Assets webhook to be fired when a given asset report has been successfully generated. If the Item does not support Assets, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `ERROR`: Assets webhook to be fired when asset report generation has failed. If the Item does not support Assets, a `SANDBOX_PRODUCT_NOT_ENABLED` error will result.  `USER_PERMISSION_REVOKED`: Indicates an end user has revoked the permission that they previously granted to access an Item. May not always fire upon revocation, as some institutions' consent portals do not trigger this webhook. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  `USER_ACCOUNT_REVOKED`: Fired when an end user has revoked access to their account on the Data Provider's portal. This webhook is currently sent only for Chase, PNC, and Truist Items, but may be sent in the future for other financial institutions. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  Note that this endpoint is provided for developer ease-of-use and is not required for testing webhooks; webhooks will also fire in Sandbox under the same conditions that they would in Production (except for webhooks of type `TRANSFER`).
     # @param sandbox_item_fire_webhook_request [SandboxItemFireWebhookRequest] 
     # @param [Hash] opts the optional parameters
     # @return [SandboxItemFireWebhookResponse]
@@ -15244,7 +15312,7 @@ module Plaid
     end
 
     # Fire a test webhook
-    # The &#x60;/sandbox/item/fire_webhook&#x60; endpoint is used to test that code correctly handles webhooks. This endpoint can trigger the following webhooks:  &#x60;DEFAULT_UPDATE&#x60;: Webhook to be fired for a given Sandbox Item simulating a default update event for the respective product as specified with the &#x60;webhook_type&#x60; in the request body. Valid Sandbox &#x60;DEFAULT_UPDATE&#x60; webhook types include: &#x60;AUTH&#x60;, &#x60;IDENTITY&#x60;, &#x60;TRANSACTIONS&#x60;, &#x60;INVESTMENTS_TRANSACTIONS&#x60;, &#x60;LIABILITIES&#x60;, &#x60;HOLDINGS&#x60;. If the Item does not support the product, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;NEW_ACCOUNTS_AVAILABLE&#x60;: Fired to indicate that a new account is available on the Item and you can launch update mode to request access to it.  &#x60;SMS_MICRODEPOSITS_VERIFICATION&#x60;: Fired when a given Same-Day Micro-deposit Item is verified via SMS verification.  &#x60;LOGIN_REPAIRED&#x60;: Fired when an Item recovers from the &#x60;ITEM_LOGIN_REQUIRED&#x60; without the user going through update mode in your app.  &#x60;PENDING_DISCONNECT&#x60;: Fired when an Item will stop working in the near future (e.g. due to a planned bank migration) and must be sent through update mode to continue working.  &#x60;RECURRING_TRANSACTIONS_UPDATE&#x60;: Recurring Transactions webhook to be fired for a given Sandbox Item. If the Item does not support Recurring Transactions, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;SYNC_UPDATES_AVAILABLE&#x60;: Transactions webhook to be fired for a given Sandbox Item.  If the Item does not support Transactions, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;PRODUCT_READY&#x60;: Assets webhook to be fired when a given asset report has been successfully generated. If the Item does not support Assets, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;ERROR&#x60;: Assets webhook to be fired when asset report generation has failed. If the Item does not support Assets, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;USER_PERMISSION_REVOKED&#x60;: Indicates an end user has revoked the permission that they previously granted to access an Item. May not always fire upon revocation, as some institutions&#39; consent portals do not trigger this webhook. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  &#x60;USER_ACCOUNT_REVOKED&#x60;: Fired when an end user has revoked access to their account on the Data Provider&#39;s portal. This webhook is currently sent only for Chase, PNC, and Truist Items, but may be sent in the future for other financial institutions. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  Note that this endpoint is provided for developer ease-of-use and is not required for testing webhooks; webhooks will also fire in Sandbox under the same conditions that they would in Production (except for webhooks of type &#x60;TRANSFER&#x60;).
+    # The &#x60;/sandbox/item/fire_webhook&#x60; endpoint is used to test that code correctly handles webhooks. This endpoint can trigger the following webhooks:  &#x60;DEFAULT_UPDATE&#x60;: Webhook to be fired for a given Sandbox Item simulating a default update event for the respective product as specified with the &#x60;webhook_type&#x60; in the request body. Valid Sandbox &#x60;DEFAULT_UPDATE&#x60; webhook types include: &#x60;AUTH&#x60;, &#x60;IDENTITY&#x60;, &#x60;TRANSACTIONS&#x60;, &#x60;INVESTMENTS_TRANSACTIONS&#x60;, &#x60;LIABILITIES&#x60;, &#x60;HOLDINGS&#x60;. If the Item does not support the product, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;NEW_ACCOUNTS_AVAILABLE&#x60;: Fired to indicate that a new account is available on the Item and you can launch update mode to request access to it.  &#x60;SMS_MICRODEPOSITS_VERIFICATION&#x60;: Fired when a given Same-Day Micro-deposit Item is verified via SMS verification.  &#x60;LOGIN_REPAIRED&#x60;: Fired when an Item recovers from the &#x60;ITEM_LOGIN_REQUIRED&#x60; without the user going through update mode in your app.  &#x60;PENDING_DISCONNECT&#x60;: Fired when an Item will stop working in the near future (e.g. due to a planned bank migration) and must be sent through update mode to continue working.  &#x60;RECURRING_TRANSACTIONS_UPDATE&#x60;: Recurring Transactions webhook to be fired for a given Sandbox Item. If your client is not enabled for Recurring Transactions, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;SYNC_UPDATES_AVAILABLE&#x60;: Transactions webhook to be fired for a given Sandbox Item.  If your client is not enabled for Transactions, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;PRODUCT_READY&#x60;: Assets webhook to be fired when a given asset report has been successfully generated. If the Item does not support Assets, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;ERROR&#x60;: Assets webhook to be fired when asset report generation has failed. If the Item does not support Assets, a &#x60;SANDBOX_PRODUCT_NOT_ENABLED&#x60; error will result.  &#x60;USER_PERMISSION_REVOKED&#x60;: Indicates an end user has revoked the permission that they previously granted to access an Item. May not always fire upon revocation, as some institutions&#39; consent portals do not trigger this webhook. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  &#x60;USER_ACCOUNT_REVOKED&#x60;: Fired when an end user has revoked access to their account on the Data Provider&#39;s portal. This webhook is currently sent only for Chase, PNC, and Truist Items, but may be sent in the future for other financial institutions. Upon receiving this webhook, it is recommended to delete any stored data from Plaid associated with the account or Item.  Note that this endpoint is provided for developer ease-of-use and is not required for testing webhooks; webhooks will also fire in Sandbox under the same conditions that they would in Production (except for webhooks of type &#x60;TRANSFER&#x60;).
     # @param sandbox_item_fire_webhook_request [SandboxItemFireWebhookRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(SandboxItemFireWebhookResponse, Integer, Hash)>] SandboxItemFireWebhookResponse data, response status code and response headers
@@ -16185,74 +16253,6 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Trigger the creation of a repayment
-    # Use the `/sandbox/transfer/repayment/simulate` endpoint to trigger the creation of a repayment. As a side effect of calling this route, a repayment is created that includes all unreimbursed returns of guaranteed transfers. If there are no such returns, a 400 error is returned.
-    # @param sandbox_transfer_repayment_simulate_request [SandboxTransferRepaymentSimulateRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [SandboxTransferRepaymentSimulateResponse]
-    def sandbox_transfer_repayment_simulate(sandbox_transfer_repayment_simulate_request, opts = {})
-      data, _status_code, _headers = sandbox_transfer_repayment_simulate_with_http_info(sandbox_transfer_repayment_simulate_request, opts)
-      data
-    end
-
-    # Trigger the creation of a repayment
-    # Use the &#x60;/sandbox/transfer/repayment/simulate&#x60; endpoint to trigger the creation of a repayment. As a side effect of calling this route, a repayment is created that includes all unreimbursed returns of guaranteed transfers. If there are no such returns, a 400 error is returned.
-    # @param sandbox_transfer_repayment_simulate_request [SandboxTransferRepaymentSimulateRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(SandboxTransferRepaymentSimulateResponse, Integer, Hash)>] SandboxTransferRepaymentSimulateResponse data, response status code and response headers
-    def sandbox_transfer_repayment_simulate_with_http_info(sandbox_transfer_repayment_simulate_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PlaidApi.sandbox_transfer_repayment_simulate ...'
-      end
-      # verify the required parameter 'sandbox_transfer_repayment_simulate_request' is set
-      if @api_client.config.client_side_validation && sandbox_transfer_repayment_simulate_request.nil?
-        fail ArgumentError, "Missing the required parameter 'sandbox_transfer_repayment_simulate_request' when calling PlaidApi.sandbox_transfer_repayment_simulate"
-      end
-      # resource path
-      local_var_path = '/sandbox/transfer/repayment/simulate'
-
-      # 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'
-      content_type = @api_client.select_header_content_type(['application/json'])
-      if !content_type.nil?
-          header_params['Content-Type'] = content_type
-      end
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:debug_body] || @api_client.object_to_http_body(sandbox_transfer_repayment_simulate_request)
-
-      # return_type
-      return_type = opts[:debug_return_type] || 'SandboxTransferRepaymentSimulateResponse'
-
-      # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
-
-      new_options = opts.merge(
-        :operation => :"PlaidApi.sandbox_transfer_repayment_simulate",
-        :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_repayment_simulate\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    end
-
     # Simulate a transfer event in Sandbox
     # Use the `/sandbox/transfer/simulate` endpoint to simulate a transfer event in the Sandbox environment.  Note that while an event will be simulated and will appear when using endpoints such as `/transfer/event/sync` or `/transfer/event/list`, no transactions will actually take place and funds will not move between accounts, even within the Sandbox.
     # @param sandbox_transfer_simulate_request [SandboxTransferSimulateRequest] 
@@ -16594,7 +16594,7 @@ module Plaid
     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.
+    # Use the `/sandbox/transfer/test_clock/list` endpoint to see a list of all your test clocks in the Sandbox environment, by descending `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]
@@ -16604,7 +16604,7 @@ module Plaid
     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.
+    # Use the &#x60;/sandbox/transfer/test_clock/list&#x60; endpoint to see a list of all your test clocks in the Sandbox environment, by descending &#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
@@ -17409,74 +17409,6 @@ module Plaid
       return data, status_code, headers
     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.
-    # @param transactions_enhance_get_request [TransactionsEnhanceGetRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [TransactionsEnhanceGetResponse]
-    def transactions_enhance(transactions_enhance_get_request, opts = {})
-      data, _status_code, _headers = transactions_enhance_with_http_info(transactions_enhance_get_request, opts)
-      data
-    end
-
-    # Enhance locally-held transaction data
-    # 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
-    def transactions_enhance_with_http_info(transactions_enhance_get_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PlaidApi.transactions_enhance ...'
-      end
-      # verify the required parameter 'transactions_enhance_get_request' is set
-      if @api_client.config.client_side_validation && transactions_enhance_get_request.nil?
-        fail ArgumentError, "Missing the required parameter 'transactions_enhance_get_request' when calling PlaidApi.transactions_enhance"
-      end
-      # resource path
-      local_var_path = '/beta/transactions/v1/enhance'
-
-      # 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'
-      content_type = @api_client.select_header_content_type(['application/json'])
-      if !content_type.nil?
-          header_params['Content-Type'] = content_type
-      end
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:debug_body] || @api_client.object_to_http_body(transactions_enhance_get_request)
-
-      # return_type
-      return_type = opts[:debug_return_type] || 'TransactionsEnhanceGetResponse'
-
-      # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
-
-      new_options = opts.merge(
-        :operation => :"PlaidApi.transactions_enhance",
-        :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#transactions_enhance\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    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.
     # @param transactions_enrich_request [TransactionsEnrichRequest] 
@@ -17546,7 +17478,7 @@ module Plaid
     end
 
     # Get transaction data
-    # Note: All new implementations are encouraged to use `/transactions/sync` rather than `/transactions/get`. `/transactions/sync` provides the same functionality as `/transactions/get` and improves developer ease-of-use for handling transactions updates. The `/transactions/get` endpoint allows developers to receive user-authorized transaction data for credit, depository, and some loan-type accounts (only those with account subtype `student` or `mortgage`; coverage may be limited). For transaction history from investment accounts, use the [Investments endpoint](https://plaid.com/docs/api/products/investments/) instead. Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available. Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in `/transactions/get`.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions). Due to the potentially large number of transactions associated with an Item, results are paginated. Manipulate the `count` and `offset` parameters in conjunction with the `total_transactions` response body field to fetch all available transactions. Data returned by `/transactions/get` will be the data available for the Item as of the most recent successful check for new transactions. 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. To find out when the Item was last updated, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call `/item/get`; the `item.status.transactions.last_successful_update` field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, you can use the `/transactions/refresh` endpoint.   Note that data may not be immediately available to `/transactions/get`. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with `transactions`, or upon the first call to `/transactions/get`, if it wasn't. To be alerted when transaction data is ready to be fetched, listen for the [`INITIAL_UPDATE`](https://plaid.com/docs/api/products/transactions/#initial_update) and [`HISTORICAL_UPDATE`](https://plaid.com/docs/api/products/transactions/#historical_update) webhooks. If no transaction history is ready when `/transactions/get` is called, it will return a `PRODUCT_NOT_READY` error.
+    # Note: All new implementations are encouraged to use `/transactions/sync` rather than `/transactions/get`. `/transactions/sync` provides the same functionality as `/transactions/get` and improves developer ease-of-use for handling transactions updates. The `/transactions/get` endpoint allows developers to receive user-authorized transaction data for credit, depository, and loan-type accounts (coverage may be limited). For transaction history from investment accounts, use the [Investments endpoint](https://plaid.com/docs/api/products/investments/) instead. Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available. Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in `/transactions/get`.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions). Due to the potentially large number of transactions associated with an Item, results are paginated. Manipulate the `count` and `offset` parameters in conjunction with the `total_transactions` response body field to fetch all available transactions. Data returned by `/transactions/get` will be the data available for the Item as of the most recent successful check for new transactions. 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. To find out when the Item was last updated, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call `/item/get`; the `item.status.transactions.last_successful_update` field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, you can use the `/transactions/refresh` endpoint.   Note that data may not be immediately available to `/transactions/get`. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with `transactions`, or upon the first call to `/transactions/get`, if it wasn't. To be alerted when transaction data is ready to be fetched, listen for the [`INITIAL_UPDATE`](https://plaid.com/docs/api/products/transactions/#initial_update) and [`HISTORICAL_UPDATE`](https://plaid.com/docs/api/products/transactions/#historical_update) webhooks. If no transaction history is ready when `/transactions/get` is called, it will return a `PRODUCT_NOT_READY` error.
     # @param transactions_get_request [TransactionsGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransactionsGetResponse]
@@ -17556,7 +17488,7 @@ module Plaid
     end
 
     # Get transaction data
-    # Note: All new implementations are encouraged to use &#x60;/transactions/sync&#x60; rather than &#x60;/transactions/get&#x60;. &#x60;/transactions/sync&#x60; provides the same functionality as &#x60;/transactions/get&#x60; and improves developer ease-of-use for handling transactions updates. The &#x60;/transactions/get&#x60; endpoint allows developers to receive user-authorized transaction data for credit, depository, and some loan-type accounts (only those with account subtype &#x60;student&#x60; or &#x60;mortgage&#x60;; coverage may be limited). For transaction history from investment accounts, use the [Investments endpoint](https://plaid.com/docs/api/products/investments/) instead. Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available. Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in &#x60;/transactions/get&#x60;.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions). Due to the potentially large number of transactions associated with an Item, results are paginated. Manipulate the &#x60;count&#x60; and &#x60;offset&#x60; parameters in conjunction with the &#x60;total_transactions&#x60; response body field to fetch all available transactions. Data returned by &#x60;/transactions/get&#x60; will be the data available for the Item as of the most recent successful check for new transactions. 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. To find out when the Item was last updated, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call &#x60;/item/get&#x60;; the &#x60;item.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, you can use the &#x60;/transactions/refresh&#x60; endpoint.   Note that data may not be immediately available to &#x60;/transactions/get&#x60;. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with &#x60;transactions&#x60;, or upon the first call to &#x60;/transactions/get&#x60;, if it wasn&#39;t. To be alerted when transaction data is ready to be fetched, listen for the [&#x60;INITIAL_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#initial_update) and [&#x60;HISTORICAL_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#historical_update) webhooks. If no transaction history is ready when &#x60;/transactions/get&#x60; is called, it will return a &#x60;PRODUCT_NOT_READY&#x60; error.
+    # Note: All new implementations are encouraged to use &#x60;/transactions/sync&#x60; rather than &#x60;/transactions/get&#x60;. &#x60;/transactions/sync&#x60; provides the same functionality as &#x60;/transactions/get&#x60; and improves developer ease-of-use for handling transactions updates. The &#x60;/transactions/get&#x60; endpoint allows developers to receive user-authorized transaction data for credit, depository, and loan-type accounts (coverage may be limited). For transaction history from investment accounts, use the [Investments endpoint](https://plaid.com/docs/api/products/investments/) instead. Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available. Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift.  Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in &#x60;/transactions/get&#x60;.  For more details, see [Pending and posted transactions](https://plaid.com/docs/transactions/transactions-data/#pending-and-posted-transactions). Due to the potentially large number of transactions associated with an Item, results are paginated. Manipulate the &#x60;count&#x60; and &#x60;offset&#x60; parameters in conjunction with the &#x60;total_transactions&#x60; response body field to fetch all available transactions. Data returned by &#x60;/transactions/get&#x60; will be the data available for the Item as of the most recent successful check for new transactions. 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. To find out when the Item was last updated, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call &#x60;/item/get&#x60;; the &#x60;item.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, you can use the &#x60;/transactions/refresh&#x60; endpoint.   Note that data may not be immediately available to &#x60;/transactions/get&#x60;. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with &#x60;transactions&#x60;, or upon the first call to &#x60;/transactions/get&#x60;, if it wasn&#39;t. To be alerted when transaction data is ready to be fetched, listen for the [&#x60;INITIAL_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#initial_update) and [&#x60;HISTORICAL_UPDATE&#x60;](https://plaid.com/docs/api/products/transactions/#historical_update) webhooks. If no transaction history is ready when &#x60;/transactions/get&#x60; is called, it will return a &#x60;PRODUCT_NOT_READY&#x60; error.
     # @param transactions_get_request [TransactionsGetRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransactionsGetResponse, Integer, Hash)>] TransactionsGetResponse data, response status code and response headers
@@ -17817,8 +17749,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Return a list of rules created for the Item associated with the access token.
-    # The `/beta/transactions/rules/v1/list` returns a list of transaction rules created for the Item associated with the access token.
+    # Return a list of rules created for the end user.
+    # The `/beta/transactions/rules/v1/list` returns a list of transaction rules created for the end user specified by `client_user_id`.
     # @param transactions_rules_list_request [TransactionsRulesListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransactionsRulesListResponse]
@@ -17827,8 +17759,8 @@ module Plaid
       data
     end
 
-    # Return a list of rules created for the Item associated with the access token.
-    # The &#x60;/beta/transactions/rules/v1/list&#x60; returns a list of transaction rules created for the Item associated with the access token.
+    # Return a list of rules created for the end user.
+    # The &#x60;/beta/transactions/rules/v1/list&#x60; returns a list of transaction rules created for the end user specified by &#x60;client_user_id&#x60;.
     # @param transactions_rules_list_request [TransactionsRulesListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransactionsRulesListResponse, Integer, Hash)>] TransactionsRulesListResponse data, response status code and response headers
@@ -17954,7 +17886,7 @@ module Plaid
     end
 
     # Get incremental transaction updates on an Item
-    # The `/transactions/sync` endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with `/transactions/sync`, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using `/transactions/get`, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports `credit`, `depository`, and some `loan`-type accounts (only those with account subtype `student` or `mortgage`). For `investments` accounts, use `/investments/transactions/get` instead.  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 (e.g. due to the [`TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION`](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the `/link/token/create` call or if `/transactions/sync` was called within a few seconds of Item creation, `/transactions/sync` will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call `/item/get`; the `item.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.  To be alerted when new transactions are available, listen for the [`SYNC_UPDATES_AVAILABLE`](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.
+    # The `/transactions/sync` endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with `/transactions/sync`, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using `/transactions/get`, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports `credit`, `depository`, and `loan`-type accounts. For `investments` accounts, use `/investments/transactions/get` instead.  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 (e.g. due to the [`TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION`](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the `/link/token/create` call or if `/transactions/sync` was called within a few seconds of Item creation, `/transactions/sync` will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call `/item/get`; the `item.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.  To be alerted when new transactions are 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]
@@ -17964,7 +17896,7 @@ module Plaid
     end
 
     # Get incremental transaction updates on an Item
-    # The &#x60;/transactions/sync&#x60; endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with &#x60;/transactions/sync&#x60;, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using &#x60;/transactions/get&#x60;, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports &#x60;credit&#x60;, &#x60;depository&#x60;, and some &#x60;loan&#x60;-type accounts (only those with account subtype &#x60;student&#x60; or &#x60;mortgage&#x60;). For &#x60;investments&#x60; accounts, use &#x60;/investments/transactions/get&#x60; instead.  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 (e.g. due to the [&#x60;TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION&#x60;](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the &#x60;/link/token/create&#x60; call or if &#x60;/transactions/sync&#x60; was called within a few seconds of Item creation, &#x60;/transactions/sync&#x60; will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call &#x60;/item/get&#x60;; the &#x60;item.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.  To be alerted when new transactions are available, listen for the [&#x60;SYNC_UPDATES_AVAILABLE&#x60;](https://plaid.com/docs/api/products/transactions/#sync_updates_available) webhook.
+    # The &#x60;/transactions/sync&#x60; endpoint retrieves transactions associated with an Item and can fetch updates using a cursor to track which updates have already been seen.  For important instructions on integrating with &#x60;/transactions/sync&#x60;, see the [Transactions integration overview](https://plaid.com/docs/transactions/#integration-overview). If you are migrating from an existing integration using &#x60;/transactions/get&#x60;, see the [Transactions Sync migration guide](https://plaid.com/docs/transactions/sync-migration/).  This endpoint supports &#x60;credit&#x60;, &#x60;depository&#x60;, and &#x60;loan&#x60;-type accounts. For &#x60;investments&#x60; accounts, use &#x60;/investments/transactions/get&#x60; instead.  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 (e.g. due to the [&#x60;TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION&#x60;](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error), 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.  If transactions data is not yet available for the Item, which can happen if the Item was not initialized with transactions during the &#x60;/link/token/create&#x60; call or if &#x60;/transactions/sync&#x60; was called within a few seconds of Item creation, &#x60;/transactions/sync&#x60; will return empty transactions arrays.  Plaid typically checks for new transactions data between one and four times per day, depending on the institution. To find out when transactions were last updated for an Item, use the [Item Debugger](https://plaid.com/docs/account/activity/#troubleshooting-with-item-debugger) or call &#x60;/item/get&#x60;; the &#x60;item.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.  To be alerted when new transactions are 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
@@ -18498,7 +18430,7 @@ module Plaid
     end
 
     # Create a transfer
-    # Use the `/transfer/create` endpoint to initiate a new transfer. This endpoint is retryable and idempotent; if a transfer with the provided `transfer_id` has already been created, it will return the transfer details without creating a new transfer. A transfer may still be created if a 500 error is returned; to detect this scenario, use [Transfer events](https://plaid.com/docs/transfer/reconciling-transfers/).
+    # Use the `/transfer/create` endpoint to initiate a new transfer. This endpoint is retryable and idempotent; if a transfer with the provided `authorization_id` has already been created, it will return the transfer details without creating a new transfer. A transfer may still be created if a 500 error is returned; to detect this scenario, use [Transfer events](https://plaid.com/docs/transfer/reconciling-transfers/).
     # @param transfer_create_request [TransferCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransferCreateResponse]
@@ -18508,7 +18440,7 @@ module Plaid
     end
 
     # Create a transfer
-    # Use the &#x60;/transfer/create&#x60; endpoint to initiate a new transfer. This endpoint is retryable and idempotent; if a transfer with the provided &#x60;transfer_id&#x60; has already been created, it will return the transfer details without creating a new transfer. A transfer may still be created if a 500 error is returned; to detect this scenario, use [Transfer events](https://plaid.com/docs/transfer/reconciling-transfers/).
+    # Use the &#x60;/transfer/create&#x60; endpoint to initiate a new transfer. This endpoint is retryable and idempotent; if a transfer with the provided &#x60;authorization_id&#x60; has already been created, it will return the transfer details without creating a new transfer. A transfer may still be created if a 500 error is returned; to detect this scenario, use [Transfer events](https://plaid.com/docs/transfer/reconciling-transfers/).
     # @param transfer_create_request [TransferCreateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransferCreateResponse, Integer, Hash)>] TransferCreateResponse data, response status code and response headers
@@ -20674,7 +20606,7 @@ module Plaid
     end
 
     # Lists historical repayments
-    # The `/transfer/repayment/list` endpoint fetches repayments matching the given filters. Repayments are returned in reverse-chronological order (most recent first) starting at the given `start_time`.
+    # The `/transfer/repayment/list` endpoint fetches repayments matching the given filters. Repayments are returned in reverse-chronological order (most recent first) starting at the given `start_date`.
     # @param transfer_repayment_list_request [TransferRepaymentListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransferRepaymentListResponse]
@@ -20684,7 +20616,7 @@ module Plaid
     end
 
     # Lists historical repayments
-    # The &#x60;/transfer/repayment/list&#x60; endpoint fetches repayments matching the given filters. Repayments are returned in reverse-chronological order (most recent first) starting at the given &#x60;start_time&#x60;.
+    # The &#x60;/transfer/repayment/list&#x60; endpoint fetches repayments matching the given filters. Repayments are returned in reverse-chronological order (most recent first) starting at the given &#x60;start_date&#x60;.
     # @param transfer_repayment_list_request [TransferRepaymentListRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransferRepaymentListResponse, Integer, Hash)>] TransferRepaymentListResponse data, response status code and response headers
@@ -20810,7 +20742,7 @@ module Plaid
     end
 
     # Report a return recovery
-    # Use the `/transfer/return/recover` endpoint to notify Plaid that you have recovered some or all of the loss on a returned guaranteed transfer.  Recovery can be reported in full or in parts; the sum of recovered amounts across calls cannot exceed the original transfer's amount.
+    # Use the `/transfer/return/recover` endpoint to notify Plaid that you have recovered some or all of the loss on a returned guaranteed transfer.  Recovery can be reported in full or in parts; the sum of recovered amounts across calls cannot exceed the guaranteed amount of the original transfer.
     # @param transfer_return_recover_request [TransferReturnRecoverRequest] 
     # @param [Hash] opts the optional parameters
     # @return [TransferReturnRecoverResponse]
@@ -20820,7 +20752,7 @@ module Plaid
     end
 
     # Report a return recovery
-    # Use the &#x60;/transfer/return/recover&#x60; endpoint to notify Plaid that you have recovered some or all of the loss on a returned guaranteed transfer.  Recovery can be reported in full or in parts; the sum of recovered amounts across calls cannot exceed the original transfer&#39;s amount.
+    # Use the &#x60;/transfer/return/recover&#x60; endpoint to notify Plaid that you have recovered some or all of the loss on a returned guaranteed transfer.  Recovery can be reported in full or in parts; the sum of recovered amounts across calls cannot exceed the guaranteed amount of the original transfer.
     # @param transfer_return_recover_request [TransferReturnRecoverRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(TransferReturnRecoverResponse, Integer, Hash)>] TransferReturnRecoverResponse data, response status code and response headers
@@ -21221,7 +21153,7 @@ module Plaid
     end
 
     # Refresh user items for Financial-Insights bundle
-    # `/user/financial_data/refresh` is an optional endpoint that initiates an on-demand extraction to fetch the newest transactions for a User using the Financial Insights bundle. This bundle refreshes the Transactions, Investments, and Liabilities product data. This endpoint is for clients who use the Financial Insights bundle and want to proactively update all linked Items under a user. The refresh may succeed or fail on a per-Item basis. Use the `results` array in the response to understand the outcome for each Item.  This endpoint is distinct from `/transactions/refresh`, which triggers a refresh for a single Item. Use `/user/financial_data/refresh` to target all Items for a user instead.
+    # `/user/financial_data/refresh` is an optional endpoint that initiates an on-demand extraction to fetch the newest transactions for a User using the Financial Insights bundle. This bundle refreshes the Transactions and Investments product data. This endpoint is for clients who use the Financial Insights bundle and want to proactively update all linked Items under a user. The refresh may succeed or fail on a per-Item basis. Use the `results` array in the response to understand the outcome for each Item.  This endpoint is distinct from `/transactions/refresh`, which triggers a refresh for a single Item. Use `/user/financial_data/refresh` to target all Items for a user instead.
     # @param user_financial_data_refresh_request [UserFinancialDataRefreshRequest] 
     # @param [Hash] opts the optional parameters
     # @return [UserFinancialDataRefreshResponse]
@@ -21231,7 +21163,7 @@ module Plaid
     end
 
     # Refresh user items for Financial-Insights bundle
-    # &#x60;/user/financial_data/refresh&#x60; is an optional endpoint that initiates an on-demand extraction to fetch the newest transactions for a User using the Financial Insights bundle. This bundle refreshes the Transactions, Investments, and Liabilities product data. This endpoint is for clients who use the Financial Insights bundle and want to proactively update all linked Items under a user. The refresh may succeed or fail on a per-Item basis. Use the &#x60;results&#x60; array in the response to understand the outcome for each Item.  This endpoint is distinct from &#x60;/transactions/refresh&#x60;, which triggers a refresh for a single Item. Use &#x60;/user/financial_data/refresh&#x60; to target all Items for a user instead.
+    # &#x60;/user/financial_data/refresh&#x60; is an optional endpoint that initiates an on-demand extraction to fetch the newest transactions for a User using the Financial Insights bundle. This bundle refreshes the Transactions and Investments product data. This endpoint is for clients who use the Financial Insights bundle and want to proactively update all linked Items under a user. The refresh may succeed or fail on a per-Item basis. Use the &#x60;results&#x60; array in the response to understand the outcome for each Item.  This endpoint is distinct from &#x60;/transactions/refresh&#x60;, which triggers a refresh for a single Item. Use &#x60;/user/financial_data/refresh&#x60; to target all Items for a user instead.
     # @param user_financial_data_refresh_request [UserFinancialDataRefreshRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(UserFinancialDataRefreshResponse, Integer, Hash)>] UserFinancialDataRefreshResponse data, response status code and response headers
@@ -21634,8 +21566,8 @@ module Plaid
       return data, status_code, headers
     end
 
-    # Terminate user-based products
-    # Terminates user-based recurring subscription bundles or products (Financial Management, Plaid Protect, and CRA Servicing) associated with a `user_id`. After you call this endpoint, the user will no longer be billed for these products. For CRA Servicing, the subscription is canceled but historical data remains available for future report requests.
+    # Terminate products for a user
+    # Terminates Financial Management, Plaid Protect, and Servicing products associated with a `user_id`. Use this endpoint when offboarding a user or ending their subscriptions. Item access tokens are not required.  For Financial Management products, including Transactions, Liabilities, and Investments, this endpoint removes each associated Item that contains one of these products. Removal makes the Item inaccessible, initiates deletion of its product data, and terminates its per-Item subscription billing. The entire Item is removed, including access to any other products on that Item. To connect the accounts again, the user must complete Link to create a new Item.  If the user has at least one associated Item and every associated Item contains a Financial Management product, this endpoint also removes the associated Plaid user. The removed `user_id` can no longer be used to access the user.  For Plaid Protect, this endpoint terminates Protect products. For Servicing, it cancels the subscription and preserves CRA Items and historical data for future report requests.
     # @param user_products_terminate_request [UserProductsTerminateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [UserProductsTerminateResponse]
@@ -21644,8 +21576,8 @@ module Plaid
       data
     end
 
-    # Terminate user-based products
-    # Terminates user-based recurring subscription bundles or products (Financial Management, Plaid Protect, and CRA Servicing) associated with a &#x60;user_id&#x60;. After you call this endpoint, the user will no longer be billed for these products. For CRA Servicing, the subscription is canceled but historical data remains available for future report requests.
+    # Terminate products for a user
+    # Terminates Financial Management, Plaid Protect, and Servicing products associated with a &#x60;user_id&#x60;. Use this endpoint when offboarding a user or ending their subscriptions. Item access tokens are not required.  For Financial Management products, including Transactions, Liabilities, and Investments, this endpoint removes each associated Item that contains one of these products. Removal makes the Item inaccessible, initiates deletion of its product data, and terminates its per-Item subscription billing. The entire Item is removed, including access to any other products on that Item. To connect the accounts again, the user must complete Link to create a new Item.  If the user has at least one associated Item and every associated Item contains a Financial Management product, this endpoint also removes the associated Plaid user. The removed &#x60;user_id&#x60; can no longer be used to access the user.  For Plaid Protect, this endpoint terminates Protect products. For Servicing, it cancels the subscription and preserves CRA Items and historical data for future report requests.
     # @param user_products_terminate_request [UserProductsTerminateRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(UserProductsTerminateResponse, Integer, Hash)>] UserProductsTerminateResponse data, response status code and response headers
@@ -22029,7 +21961,7 @@ module Plaid
       return_type = opts[:debug_return_type] || 'UserUpdateResponse'
 
       # auth_names
-      auth_names = opts[:debug_auth_names] || ['clientId', 'plaidVersion', 'secret']
+      auth_names = opts[:debug_auth_names] || ['clientId', 'oauth2', 'plaidVersion', 'secret']
 
       new_options = opts.merge(
         :operation => :"PlaidApi.user_update",