lithic 0.1.0.pre.alpha.5 → 0.1.0.pre.alpha.7

data/lib/lithic/resources/accounts.rb

@@ -23,8 +23,8 @@ module Lithic
       end
 
       # Update account configuration such as state or spend limits. Can only be run on
-      #   accounts that are part of the program managed by this API key. Accounts that are
-      #   in the `PAUSED` state will not be able to transact or create new cards.
+      # accounts that are part of the program managed by this API key. Accounts that are
+      # in the `PAUSED` state will not be able to transact or create new cards.
       #
       # @overload update(account_token, daily_spend_limit: nil, lifetime_spend_limit: nil, monthly_spend_limit: nil, state: nil, verification_address: nil, request_options: {})
       #
@@ -69,7 +69,7 @@ module Lithic
         @client.request(
           method: :get,
           path: "v1/accounts",
-          query: parsed,
+          query: parsed.transform_keys(begin_: "begin", end_: "end"),
           page: Lithic::Internal::CursorPage,
           model: Lithic::Models::Account,
           options: options
@@ -77,10 +77,10 @@ module Lithic
       end
 
       # Get an Account's available spend limits, which is based on the spend limit
-      #   configured on the Account and the amount already spent over the spend limit's
-      #   duration. For example, if the Account has a daily spend limit of $1000
-      #   configured, and has spent $600 in the last 24 hours, the available spend limit
-      #   returned would be $400.
+      # configured on the Account and the amount already spent over the spend limit's
+      # duration. For example, if the Account has a daily spend limit of $1000
+      # configured, and has spent $600 in the last 24 hours, the available spend limit
+      # returned would be $400.
       #
       # @overload retrieve_spend_limits(account_token, request_options: {})
       #

data/lib/lithic/resources/aggregate_balances.rb

@@ -4,7 +4,7 @@ module Lithic
   module Resources
     class AggregateBalances
       # Get the aggregated balance across all end-user accounts by financial account
-      #   type
+      # type
       #
       # @overload list(financial_account_type: nil, request_options: {})
       #

data/lib/lithic/resources/auth_rules/v2/backtests.rb

@@ -6,30 +6,30 @@ module Lithic
       class V2
         class Backtests
           # Initiates a request to asynchronously generate a backtest for an authorization
-          #   rule. During backtesting, both the active version (if one exists) and the draft
-          #   version of the Authorization Rule are evaluated by replaying historical
-          #   transaction data against the rule's conditions. This process allows customers to
-          #   simulate and understand the effects of proposed rule changes before deployment.
-          #   The generated backtest report provides detailed results showing whether the
-          #   draft version of the Auth Rule would have approved or declined historical
-          #   transactions which were processed during the backtest period. These reports help
-          #   evaluate how changes to rule configurations might affect overall transaction
-          #   approval rates.
+          # rule. During backtesting, both the active version (if one exists) and the draft
+          # version of the Authorization Rule are evaluated by replaying historical
+          # transaction data against the rule's conditions. This process allows customers to
+          # simulate and understand the effects of proposed rule changes before deployment.
+          # The generated backtest report provides detailed results showing whether the
+          # draft version of the Auth Rule would have approved or declined historical
+          # transactions which were processed during the backtest period. These reports help
+          # evaluate how changes to rule configurations might affect overall transaction
+          # approval rates.
           #
-          #   The generated backtest report will be delivered asynchronously through a webhook
-          #   with `event_type` = `auth_rules.backtest_report.created`. See the docs on
-          #   setting up [webhook subscriptions](https://docs.lithic.com/docs/events-api). It
-          #   is also possible to request backtest reports on-demand through the
-          #   `/v2/auth_rules/{auth_rule_token}/backtests/{auth_rule_backtest_token}`
-          #   endpoint.
+          # The generated backtest report will be delivered asynchronously through a webhook
+          # with `event_type` = `auth_rules.backtest_report.created`. See the docs on
+          # setting up [webhook subscriptions](https://docs.lithic.com/docs/events-api). It
+          # is also possible to request backtest reports on-demand through the
+          # `/v2/auth_rules/{auth_rule_token}/backtests/{auth_rule_backtest_token}`
+          # endpoint.
           #
-          #   Lithic currently supports backtesting for `CONDITIONAL_BLOCK` rules. Backtesting
-          #   for `VELOCITY_LIMIT` rules is generally not supported. In specific cases (i.e.
-          #   where Lithic has pre-calculated the requested velocity metrics for historical
-          #   transactions), a backtest may be feasible. However, such cases are uncommon and
-          #   customers should not anticipate support for velocity backtests under most
-          #   configurations. If a historical transaction does not feature the required inputs
-          #   to evaluate the rule, then it will not be included in the final backtest report.
+          # Lithic currently supports backtesting for `CONDITIONAL_BLOCK` rules. Backtesting
+          # for `VELOCITY_LIMIT` rules is generally not supported. In specific cases (i.e.
+          # where Lithic has pre-calculated the requested velocity metrics for historical
+          # transactions), a backtest may be feasible. However, such cases are uncommon and
+          # customers should not anticipate support for velocity backtests under most
+          # configurations. If a historical transaction does not feature the required inputs
+          # to evaluate the rule, then it will not be included in the final backtest report.
           #
           # @overload create(auth_rule_token, end_: nil, start: nil, request_options: {})
           #
@@ -54,22 +54,22 @@ module Lithic
 
           # Returns the backtest results of an authorization rule (if available).
           #
-          #   Backtesting is an asynchronous process that requires time to complete. If a
-          #   customer retrieves the backtest results using this endpoint before the report is
-          #   fully generated, the response will return null for `results.current_version` and
-          #   `results.draft_version`. Customers are advised to wait for the backtest creation
-          #   process to complete (as indicated by the webhook event
-          #   auth_rules.backtest_report.created) before retrieving results from this
-          #   endpoint.
+          # Backtesting is an asynchronous process that requires time to complete. If a
+          # customer retrieves the backtest results using this endpoint before the report is
+          # fully generated, the response will return null for `results.current_version` and
+          # `results.draft_version`. Customers are advised to wait for the backtest creation
+          # process to complete (as indicated by the webhook event
+          # auth_rules.backtest_report.created) before retrieving results from this
+          # endpoint.
           #
-          #   Backtesting is an asynchronous process, while the backtest is being processed,
-          #   results will not be available which will cause `results.current_version` and
-          #   `results.draft_version` objects to contain `null`. The entries in `results` will
-          #   also always represent the configuration of the rule at the time requests are
-          #   made to this endpoint. For example, the results for `current_version` in the
-          #   served backtest report will be consistent with which version of the rule is
-          #   currently activated in the Auth Stream, regardless of which version of the rule
-          #   was active in the Auth Stream at the time a backtest is requested.
+          # Backtesting is an asynchronous process, while the backtest is being processed,
+          # results will not be available which will cause `results.current_version` and
+          # `results.draft_version` objects to contain `null`. The entries in `results` will
+          # also always represent the configuration of the rule at the time requests are
+          # made to this endpoint. For example, the results for `current_version` in the
+          # served backtest report will be consistent with which version of the rule is
+          # currently activated in the Auth Stream, regardless of which version of the rule
+          # was active in the Auth Stream at the time a backtest is requested.
           #
           # @overload retrieve(auth_rule_backtest_token, auth_rule_token:, request_options: {})
           #

data/lib/lithic/resources/auth_rules/v2.rb

@@ -55,9 +55,9 @@ module Lithic
 
         # Updates a V2 authorization rule's properties
         #
-        #   If `account_tokens`, `card_tokens`, `program_level`, or `excluded_card_tokens`
-        #   is provided, this will replace existing associations with the provided list of
-        #   entities.
+        # If `account_tokens`, `card_tokens`, `program_level`, or `excluded_card_tokens`
+        # is provided, this will replace existing associations with the provided list of
+        # entities.
         #
         # @overload update(auth_rule_token, account_tokens: nil, name: nil, state: nil, card_tokens: nil, excluded_card_tokens: nil, program_level: nil, request_options: {})
         #
@@ -130,9 +130,9 @@ module Lithic
         end
 
         # Associates a V2 authorization rule with a card program, the provided account(s)
-        #   or card(s).
+        # or card(s).
         #
-        #   Prefer using the `PATCH` method for this operation.
+        # Prefer using the `PATCH` method for this operation.
         #
         # @overload apply(auth_rule_token, account_tokens:, card_tokens:, program_level:, excluded_card_tokens: nil, request_options: {})
         #
@@ -159,8 +159,8 @@ module Lithic
 
         # Creates a new draft version of a rule that will be ran in shadow mode.
         #
-        #   This can also be utilized to reset the draft parameters, causing a draft version
-        #   to no longer be ran in shadow mode.
+        # This can also be utilized to reset the draft parameters, causing a draft version
+        # to no longer be ran in shadow mode.
         #
         # @overload draft(auth_rule_token, parameters: nil, request_options: {})
         #
@@ -183,7 +183,7 @@ module Lithic
         end
 
         # Promotes the draft version of an authorization rule to the currently active
-        #   version such that it is enforced in the authorization stream.
+        # version such that it is enforced in the authorization stream.
         #
         # @overload promote(auth_rule_token, request_options: {})
         #
@@ -203,56 +203,56 @@ module Lithic
         end
 
         # Requests a performance report of an authorization rule to be asynchronously
-        #   generated. Reports can only be run on rules in draft or active mode and will
-        #   included approved and declined statistics as well as examples. The generated
-        #   report will be delivered asynchronously through a webhook with `event_type` =
-        #   `auth_rules.performance_report.created`. See the docs on setting up
-        #   [webhook subscriptions](https://docs.lithic.com/docs/events-api).
-        #
-        #   Reports are generated based on data collected by Lithic's authorization
-        #   processing system in the trailing week. The performance of the auth rule will be
-        #   assessed on the configuration of the auth rule at the time the report is
-        #   requested. This implies that if a performance report is requested, right after
-        #   updating an auth rule, depending on the number of authorizations processed for a
-        #   card program, it may be the case that no data is available for the report.
-        #   Therefore Lithic recommends to decouple making updates to an Auth Rule, and
-        #   requesting performance reports.
-        #
-        #   To make this concrete, consider the following example:
-        #
-        #   1. At time `t`, a new Auth Rule is created, and applies to all authorizations on
-        #      a card program. The Auth Rule has not yet been promoted, causing the draft
-        #      version of the rule to be applied in shadow mode.
-        #   2. At time `t + 1 hour` a performance report is requested for the Auth Rule.
-        #      This performance report will _only_ contain data for the Auth Rule being
-        #      executed in the window between `t` and `t + 1 hour`. This is because Lithic's
-        #      transaction processing system will only start capturing data for the Auth
-        #      Rule at the time it is created.
-        #   3. At time `t + 2 hours` the draft version of the Auth Rule is promoted to the
-        #      active version of the Auth Rule by calling the
-        #      `/v2/auth_rules/{auth_rule_token}/promote` endpoint. If a performance report
-        #      is requested at this moment it will still only contain data for this version
-        #      of the rule, but the window of available data will now span from `t` to
-        #      `t + 2 hours`.
-        #   4. At time `t + 3 hours` a new version of the rule is drafted by calling the
-        #      `/v2/auth_rules/{auth_rule_token}/draft` endpoint. If a performance report is
-        #      requested right at this moment, it will only contain data for authorizations
-        #      to which both the active version and the draft version is applied. Lithic
-        #      does this to ensure that performance reports represent a fair comparison
-        #      between rules. Because there may be no authorizations in this window, and
-        #      because there may be some lag before data is available in a performance
-        #      report, the requested performance report could contain no to little data.
-        #   5. At time `t + 4 hours` another performance report is requested: this time the
-        #      performance report will contain data from the window between `t + 3 hours`
-        #      and `t + 4 hours`, for any authorizations to which both the current version
-        #      of the authorization rule (in enforcing mode) and the draft version of the
-        #      authorization rule (in shadow mode) applied.
-        #
-        #   Note that generating a report may take up to 15 minutes and that delivery is not
-        #   guaranteed. Customers are required to have created an event subscription to
-        #   receive the webhook. Additionally, there is a delay of approximately 15 minutes
-        #   between when Lithic's transaction processing systems have processed the
-        #   transaction, and when a transaction will be included in the report.
+        # generated. Reports can only be run on rules in draft or active mode and will
+        # included approved and declined statistics as well as examples. The generated
+        # report will be delivered asynchronously through a webhook with `event_type` =
+        # `auth_rules.performance_report.created`. See the docs on setting up
+        # [webhook subscriptions](https://docs.lithic.com/docs/events-api).
+        #
+        # Reports are generated based on data collected by Lithic's authorization
+        # processing system in the trailing week. The performance of the auth rule will be
+        # assessed on the configuration of the auth rule at the time the report is
+        # requested. This implies that if a performance report is requested, right after
+        # updating an auth rule, depending on the number of authorizations processed for a
+        # card program, it may be the case that no data is available for the report.
+        # Therefore Lithic recommends to decouple making updates to an Auth Rule, and
+        # requesting performance reports.
+        #
+        # To make this concrete, consider the following example:
+        #
+        # 1. At time `t`, a new Auth Rule is created, and applies to all authorizations on
+        #    a card program. The Auth Rule has not yet been promoted, causing the draft
+        #    version of the rule to be applied in shadow mode.
+        # 2. At time `t + 1 hour` a performance report is requested for the Auth Rule.
+        #    This performance report will _only_ contain data for the Auth Rule being
+        #    executed in the window between `t` and `t + 1 hour`. This is because Lithic's
+        #    transaction processing system will only start capturing data for the Auth
+        #    Rule at the time it is created.
+        # 3. At time `t + 2 hours` the draft version of the Auth Rule is promoted to the
+        #    active version of the Auth Rule by calling the
+        #    `/v2/auth_rules/{auth_rule_token}/promote` endpoint. If a performance report
+        #    is requested at this moment it will still only contain data for this version
+        #    of the rule, but the window of available data will now span from `t` to
+        #    `t + 2 hours`.
+        # 4. At time `t + 3 hours` a new version of the rule is drafted by calling the
+        #    `/v2/auth_rules/{auth_rule_token}/draft` endpoint. If a performance report is
+        #    requested right at this moment, it will only contain data for authorizations
+        #    to which both the active version and the draft version is applied. Lithic
+        #    does this to ensure that performance reports represent a fair comparison
+        #    between rules. Because there may be no authorizations in this window, and
+        #    because there may be some lag before data is available in a performance
+        #    report, the requested performance report could contain no to little data.
+        # 5. At time `t + 4 hours` another performance report is requested: this time the
+        #    performance report will contain data from the window between `t + 3 hours`
+        #    and `t + 4 hours`, for any authorizations to which both the current version
+        #    of the authorization rule (in enforcing mode) and the draft version of the
+        #    authorization rule (in shadow mode) applied.
+        #
+        # Note that generating a report may take up to 15 minutes and that delivery is not
+        # guaranteed. Customers are required to have created an event subscription to
+        # receive the webhook. Additionally, there is a delay of approximately 15 minutes
+        # between when Lithic's transaction processing systems have processed the
+        # transaction, and when a transaction will be included in the report.
         #
         # @overload report(auth_rule_token, request_options: {})
         #

data/lib/lithic/resources/auth_stream_enrollment.rb

@@ -4,11 +4,11 @@ module Lithic
   module Resources
     class AuthStreamEnrollment
       # Retrieve the ASA HMAC secret key. If one does not exist for your program yet,
-      #   calling this endpoint will create one for you. The headers (which you can use to
-      #   verify webhooks) will begin appearing shortly after calling this endpoint for
-      #   the first time. See
-      #   [this page](https://docs.lithic.com/docs/auth-stream-access-asa#asa-webhook-verification)
-      #   for more detail about verifying ASA webhooks.
+      # calling this endpoint will create one for you. The headers (which you can use to
+      # verify webhooks) will begin appearing shortly after calling this endpoint for
+      # the first time. See
+      # [this page](https://docs.lithic.com/docs/auth-stream-access-asa#asa-webhook-verification)
+      # for more detail about verifying ASA webhooks.
       #
       # @overload retrieve_secret(request_options: {})
       #
@@ -27,9 +27,9 @@ module Lithic
       end
 
       # Generate a new ASA HMAC secret key. The old ASA HMAC secret key will be
-      #   deactivated 24 hours after a successful request to this endpoint. Make a
-      #   [`GET /auth_stream/secret`](https://docs.lithic.com/reference/getauthstreamsecret)
-      #   request to retrieve the new secret key.
+      # deactivated 24 hours after a successful request to this endpoint. Make a
+      # [`GET /auth_stream/secret`](https://docs.lithic.com/reference/getauthstreamsecret)
+      # request to retrieve the new secret key.
       #
       # @overload rotate_secret(request_options: {})
       #

data/lib/lithic/resources/book_transfers.rb

@@ -4,7 +4,7 @@ module Lithic
   module Resources
     class BookTransfers
       # Book transfer funds between two financial accounts or between a financial
-      #   account and card
+      # account and card
       #
       # @overload create(amount:, category:, from_financial_account_token:, subtype:, to_financial_account_token:, type:, token: nil, memo: nil, request_options: {})
       #
@@ -76,7 +76,7 @@ module Lithic
         @client.request(
           method: :get,
           path: "v1/book_transfers",
-          query: parsed,
+          query: parsed.transform_keys(begin_: "begin", end_: "end"),
           page: Lithic::Internal::CursorPage,
           model: Lithic::Models::BookTransferResponse,
           options: options

data/lib/lithic/resources/cards/financial_transactions.rb

@@ -51,7 +51,7 @@ module Lithic
           @client.request(
             method: :get,
             path: ["v1/cards/%1$s/financial_transactions", card_token],
-            query: parsed,
+            query: parsed.transform_keys(begin_: "begin", end_: "end"),
             page: Lithic::Internal::SinglePage,
             model: Lithic::Models::FinancialTransaction,
             options: options

data/lib/lithic/resources/cards.rb

@@ -13,7 +13,7 @@ module Lithic
       attr_reader :financial_transactions
 
       # Create a new virtual or physical card. Parameters `shipping_address` and
-      #   `product_id` only apply to physical cards.
+      # `product_id` only apply to physical cards.
       #
       # @overload create(type:, account_token: nil, card_program_token: nil, carrier: nil, digital_card_art_token: nil, exp_month: nil, exp_year: nil, memo: nil, pin: nil, product_id: nil, replacement_account_token: nil, replacement_for: nil, shipping_address: nil, shipping_method: nil, spend_limit: nil, spend_limit_duration: nil, state: nil, request_options: {})
       #
@@ -70,10 +70,10 @@ module Lithic
       end
 
       # Update the specified properties of the card. Unsupplied properties will remain
-      #   unchanged.
+      # unchanged.
       #
-      #   _Note: setting a card to a `CLOSED` state is a final action that cannot be
-      #   undone._
+      # _Note: setting a card to a `CLOSED` state is a final action that cannot be
+      # undone._
       #
       # @overload update(card_token, digital_card_art_token: nil, memo: nil, pin: nil, pin_status: nil, spend_limit: nil, spend_limit_duration: nil, state: nil, request_options: {})
       #
@@ -122,7 +122,7 @@ module Lithic
         @client.request(
           method: :get,
           path: "v1/cards",
-          query: parsed,
+          query: parsed.transform_keys(begin_: "begin", end_: "end"),
           page: Lithic::Internal::CursorPage,
           model: Lithic::Models::Card,
           options: options
@@ -130,15 +130,15 @@ module Lithic
       end
 
       # Convert a virtual card into a physical card and manufacture it. Customer must
-      #   supply relevant fields for physical card creation including `product_id`,
-      #   `carrier`, `shipping_method`, and `shipping_address`. The card token will be
-      #   unchanged. The card's type will be altered to `PHYSICAL`. The card will be set
-      #   to state `PENDING_FULFILLMENT` and fulfilled at next fulfillment cycle. Virtual
-      #   cards created on card programs which do not support physical cards cannot be
-      #   converted. The card program cannot be changed as part of the conversion. Cards
-      #   must be in an `OPEN` state to be converted. Only applies to cards of type
-      #   `VIRTUAL` (or existing cards with deprecated types of `DIGITAL_WALLET` and
-      #   `UNLOCKED`).
+      # supply relevant fields for physical card creation including `product_id`,
+      # `carrier`, `shipping_method`, and `shipping_address`. The card token will be
+      # unchanged. The card's type will be altered to `PHYSICAL`. The card will be set
+      # to state `PENDING_FULFILLMENT` and fulfilled at next fulfillment cycle. Virtual
+      # cards created on card programs which do not support physical cards cannot be
+      # converted. The card program cannot be changed as part of the conversion. Cards
+      # must be in an `OPEN` state to be converted. Only applies to cards of type
+      # `VIRTUAL` (or existing cards with deprecated types of `DIGITAL_WALLET` and
+      # `UNLOCKED`).
       #
       # @overload convert_physical(card_token, shipping_address:, carrier: nil, product_id: nil, shipping_method: nil, request_options: {})
       #
@@ -164,32 +164,32 @@ module Lithic
       end
 
       # Handling full card PANs and CVV codes requires that you comply with the Payment
-      #   Card Industry Data Security Standards (PCI DSS). Some clients choose to reduce
-      #   their compliance obligations by leveraging our embedded card UI solution
-      #   documented below.
-      #
-      #   In this setup, PANs and CVV codes are presented to the end-user via a card UI
-      #   that we provide, optionally styled in the customer's branding using a specified
-      #   css stylesheet. A user's browser makes the request directly to api.lithic.com,
-      #   so card PANs and CVVs never touch the API customer's servers while full card
-      #   data is displayed to their end-users. The response contains an HTML document
-      #   (see Embedded Card UI or Changelog for upcoming changes in January). This means
-      #   that the url for the request can be inserted straight into the `src` attribute
-      #   of an iframe.
-      #
-      #   ```html
-      #   <iframe
-      #     id="card-iframe"
-      #     src="https://sandbox.lithic.com/v1/embed/card?embed_request=eyJjc3MiO...;hmac=r8tx1..."
-      #     allow="clipboard-write"
-      #     class="content"
-      #   ></iframe>
-      #   ```
-      #
-      #   You should compute the request payload on the server side. You can render it (or
-      #   the whole iframe) on the server or make an ajax call from your front end code,
-      #   but **do not ever embed your API key into front end code, as doing so introduces
-      #   a serious security vulnerability**.
+      # Card Industry Data Security Standards (PCI DSS). Some clients choose to reduce
+      # their compliance obligations by leveraging our embedded card UI solution
+      # documented below.
+      #
+      # In this setup, PANs and CVV codes are presented to the end-user via a card UI
+      # that we provide, optionally styled in the customer's branding using a specified
+      # css stylesheet. A user's browser makes the request directly to api.lithic.com,
+      # so card PANs and CVVs never touch the API customer's servers while full card
+      # data is displayed to their end-users. The response contains an HTML document
+      # (see Embedded Card UI or Changelog for upcoming changes in January). This means
+      # that the url for the request can be inserted straight into the `src` attribute
+      # of an iframe.
+      #
+      # ```html
+      # <iframe
+      #   id="card-iframe"
+      #   src="https://sandbox.lithic.com/v1/embed/card?embed_request=eyJjc3MiO...;hmac=r8tx1..."
+      #   allow="clipboard-write"
+      #   class="content"
+      # ></iframe>
+      # ```
+      #
+      # You should compute the request payload on the server side. You can render it (or
+      # the whole iframe) on the server or make an ajax call from your front end code,
+      # but **do not ever embed your API key into front end code, as doing so introduces
+      # a serious security vulnerability**.
       #
       # @overload embed(embed_request:, hmac:, request_options: {})
       #
@@ -213,11 +213,11 @@ module Lithic
       end
 
       # Allow your cardholders to directly add payment cards to the device's digital
-      #   wallet (e.g. Apple Pay) with one touch from your app.
+      # wallet (e.g. Apple Pay) with one touch from your app.
       #
-      #   This requires some additional setup and configuration. Please
-      #   [Contact Us](https://lithic.com/contact) or your Customer Success representative
-      #   for more information.
+      # This requires some additional setup and configuration. Please
+      # [Contact Us](https://lithic.com/contact) or your Customer Success representative
+      # for more information.
       #
       # @overload provision(card_token, certificate: nil, client_device_id: nil, client_wallet_account_id: nil, digital_wallet: nil, nonce: nil, nonce_signature: nil, request_options: {})
       #
@@ -245,10 +245,10 @@ module Lithic
       end
 
       # Initiate print and shipment of a duplicate physical card (e.g. card is
-      #   physically damaged). The PAN, expiry, and CVC2 will remain the same and the
-      #   original card can continue to be used until the new card is activated. Only
-      #   applies to cards of type `PHYSICAL`. A card can be replaced or renewed a total
-      #   of 8 times.
+      # physically damaged). The PAN, expiry, and CVC2 will remain the same and the
+      # original card can continue to be used until the new card is activated. Only
+      # applies to cards of type `PHYSICAL`. A card can be replaced or renewed a total
+      # of 8 times.
       #
       # @overload reissue(card_token, carrier: nil, product_id: nil, shipping_address: nil, shipping_method: nil, request_options: {})
       #
@@ -273,12 +273,15 @@ module Lithic
         )
       end
 
-      # Creates a new card with the same card token and PAN, but updated expiry and CVC2
-      #   code. The original card will keep working for card-present transactions until
-      #   the new card is activated. For card-not-present transactions, the original card
-      #   details (expiry, CVC2) will also keep working until the new card is activated.
-      #   Applies to card types `PHYSICAL` and `VIRTUAL`. A card can be replaced or
-      #   renewed a total of 8 times.
+      # Applies to card types `PHYSICAL` and `VIRTUAL`. For `PHYSICAL`, creates a new
+      # card with the same card token and PAN, but updated expiry and CVC2 code. The
+      # original card will keep working for card-present transactions until the new card
+      # is activated. For card-not-present transactions, the original card details
+      # (expiry, CVC2) will also keep working until the new card is activated. A
+      # `PHYSICAL` card can be replaced or renewed a total of 8 times. For `VIRTUAL`,
+      # the card will retain the same card token and PAN and receive an updated expiry
+      # and CVC2 code. `product_id`, `shipping_method`, `shipping_address`, `carrier`
+      # are only relevant for renewing `PHYSICAL` cards.
       #
       # @overload renew(card_token, shipping_address:, carrier: nil, exp_month: nil, exp_year: nil, product_id: nil, shipping_method: nil, request_options: {})
       #
@@ -306,9 +309,9 @@ module Lithic
       end
 
       # Get a Card's available spend limit, which is based on the spend limit configured
-      #   on the Card and the amount already spent over the spend limit's duration. For
-      #   example, if the Card has a monthly spend limit of $1000 configured, and has
-      #   spent $600 in the last month, the available spend limit returned would be $400.
+      # on the Card and the amount already spent over the spend limit's duration. For
+      # example, if the Card has a monthly spend limit of $1000 configured, and has
+      # spent $600 in the last month, the available spend limit returned would be $400.
       #
       # @overload retrieve_spend_limits(card_token, request_options: {})
       #
@@ -328,10 +331,10 @@ module Lithic
       end
 
       # Get card configuration such as spend limit and state. Customers must be PCI
-      #   compliant to use this endpoint. Please contact
-      #   [support@lithic.com](mailto:support@lithic.com) for questions. _Note: this is a
-      #   `POST` endpoint because it is more secure to send sensitive data in a request
-      #   body than in a URL._
+      # compliant to use this endpoint. Please contact
+      # [support@lithic.com](mailto:support@lithic.com) for questions. _Note: this is a
+      # `POST` endpoint because it is more secure to send sensitive data in a request
+      # body than in a URL._
       #
       # @overload search_by_pan(pan:, request_options: {})
       #

data/lib/lithic/resources/disputes.rb

@@ -93,7 +93,7 @@ module Lithic
         @client.request(
           method: :get,
           path: "v1/disputes",
-          query: parsed,
+          query: parsed.transform_keys(begin_: "begin", end_: "end"),
           page: Lithic::Internal::CursorPage,
           model: Lithic::Models::Dispute,
           options: options
@@ -120,7 +120,7 @@ module Lithic
       end
 
       # Soft delete evidence for a dispute. Evidence will not be reviewed or submitted
-      #   by Lithic after it is withdrawn.
+      # by Lithic after it is withdrawn.
       #
       # @overload delete_evidence(evidence_token, dispute_token:, request_options: {})
       #
@@ -146,10 +146,10 @@ module Lithic
       end
 
       # Use this endpoint to upload evidences for the dispute. It will return a URL to
-      #   upload your documents to. The URL will expire in 30 minutes.
+      # upload your documents to. The URL will expire in 30 minutes.
       #
-      #   Uploaded documents must either be a `jpg`, `png` or `pdf` file, and each must be
-      #   less than 5 GiB.
+      # Uploaded documents must either be a `jpg`, `png` or `pdf` file, and each must be
+      # less than 5 GiB.
       #
       # @overload initiate_evidence_upload(dispute_token, filename: nil, request_options: {})
       #
@@ -191,7 +191,7 @@ module Lithic
         @client.request(
           method: :get,
           path: ["v1/disputes/%1$s/evidences", dispute_token],
-          query: parsed,
+          query: parsed.transform_keys(begin_: "begin", end_: "end"),
           page: Lithic::Internal::CursorPage,
           model: Lithic::Models::DisputeEvidence,
           options: options

data/lib/lithic/resources/events/event_subscriptions.rb

@@ -0,0 +1,41 @@
+# frozen_string_literal: true
+
+module Lithic
+  module Resources
+    class Events
+      class EventSubscriptions
+        # Resend an event to an event subscription.
+        #
+        # @overload resend(event_subscription_token, event_token:, request_options: {})
+        #
+        # @param event_subscription_token [String]
+        # @param event_token [String]
+        # @param request_options [Lithic::RequestOptions, Hash{Symbol=>Object}, nil]
+        #
+        # @return [nil]
+        #
+        # @see Lithic::Models::Events::EventSubscriptionResendParams
+        def resend(event_subscription_token, params)
+          parsed, options = Lithic::Models::Events::EventSubscriptionResendParams.dump_request(params)
+          event_token =
+            parsed.delete(:event_token) do
+              raise ArgumentError.new("missing required path argument #{_1}")
+            end
+          @client.request(
+            method: :post,
+            path: ["v1/events/%1$s/event_subscriptions/%2$s/resend", event_token, event_subscription_token],
+            model: NilClass,
+            options: options
+          )
+        end
+
+        # @api private
+        #
+        # @param client [Lithic::Client]
+        def initialize(client:)
+          @client = client
+        end
+      end
+    end
+  end
+end