lithic 0.1.0.pre.alpha.6 → 0.1.0.pre.alpha.8

data/lib/lithic/resources/account_holders.rb

@@ -4,12 +4,12 @@ module Lithic
   module Resources
     class AccountHolders
       # Create an account holder and initiate the appropriate onboarding workflow.
-      #   Account holders and accounts have a 1:1 relationship. When an account holder is
-      #   successfully created an associated account is also created. All calls to this
-      #   endpoint will return an immediate response - though in some cases, the response
-      #   may indicate the enrollment is under review or further action will be needed to
-      #   complete the account enrollment process. This endpoint can only be used on
-      #   accounts that are part of the program that the calling API key manages.
+      # Account holders and accounts have a 1:1 relationship. When an account holder is
+      # successfully created an associated account is also created. All calls to this
+      # endpoint will return an immediate response - though in some cases, the response
+      # may indicate the enrollment is under review or further action will be needed to
+      # complete the account enrollment process. This endpoint can only be used on
+      # accounts that are part of the program that the calling API key manages.
       #
       # @overload create(beneficial_owner_individuals:, business_entity:, control_person:, nature_of_business:, tos_timestamp:, workflow:, individual:, address:, email:, first_name:, kyc_exemption_type:, last_name:, phone_number:, beneficial_owner_entities: nil, external_id: nil, kyb_passed_timestamp: nil, website_url: nil, kyc_passed_timestamp: nil, business_account_token: nil, request_options: {})
       #
@@ -49,7 +49,7 @@ module Lithic
       end
 
       # Get an Individual or Business Account Holder and/or their KYC or KYB evaluation
-      #   status.
+      # status.
       #
       # @overload retrieve(account_holder_token, request_options: {})
       #
@@ -69,14 +69,14 @@ module Lithic
       end
 
       # Update the information associated with a particular account holder (including
-      #   business owners and control persons associated to a business account). If Lithic
-      #   is performing KYB or KYC and additional verification is required we will run the
-      #   individual's or business's updated information again and return whether the
-      #   status is accepted or pending (i.e., further action required). All calls to this
-      #   endpoint will return an immediate response - though in some cases, the response
-      #   may indicate the workflow is under review or further action will be needed to
-      #   complete the evaluation process. This endpoint can only be used on existing
-      #   accounts that are part of the program that the calling API key manages.
+      # business owners and control persons associated to a business account). If Lithic
+      # is performing KYB or KYC and additional verification is required we will run the
+      # individual's or business's updated information again and return whether the
+      # status is accepted or pending (i.e., further action required). All calls to this
+      # endpoint will return an immediate response - though in some cases, the response
+      # may indicate the workflow is under review or further action will be needed to
+      # complete the evaluation process. This endpoint can only be used on existing
+      # accounts that are part of the program that the calling API key manages.
       #
       # @overload update(account_holder_token, beneficial_owner_entities: nil, beneficial_owner_individuals: nil, business_entity: nil, control_person: nil, external_id: nil, nature_of_business: nil, website_url: nil, individual: nil, address: nil, business_account_token: nil, email: nil, first_name: nil, last_name: nil, legal_business_name: nil, phone_number: nil, request_options: {})
       #
@@ -113,7 +113,7 @@ module Lithic
       end
 
       # Get a list of individual or business account holders and their KYC or KYB
-      #   evaluation status.
+      # evaluation status.
       #
       # @overload list(begin_: nil, email: nil, end_: nil, ending_before: nil, external_id: nil, first_name: nil, last_name: nil, legal_business_name: nil, limit: nil, phone_number: nil, starting_after: nil, request_options: {})
       #
@@ -138,7 +138,7 @@ module Lithic
         @client.request(
           method: :get,
           path: "v1/account_holders",
-          query: parsed.transform_keys(begin_: :begin, end_: :end),
+          query: parsed.transform_keys(begin_: "begin", end_: "end"),
           page: Lithic::Internal::SinglePage,
           model: Lithic::Models::AccountHolder,
           options: options
@@ -146,20 +146,20 @@ module Lithic
       end
 
       # Retrieve the status of account holder document uploads, or retrieve the upload
-      #   URLs to process your image uploads.
+      # URLs to process your image uploads.
       #
-      #   Note that this is not equivalent to checking the status of the KYC evaluation
-      #   overall (a document may be successfully uploaded but not be sufficient for KYC
-      #   to pass).
+      # Note that this is not equivalent to checking the status of the KYC evaluation
+      # overall (a document may be successfully uploaded but not be sufficient for KYC
+      # to pass).
       #
-      #   In the event your upload URLs have expired, calling this endpoint will refresh
-      #   them. Similarly, in the event a previous account holder document upload has
-      #   failed, you can use this endpoint to get a new upload URL for the failed image
-      #   upload.
+      # In the event your upload URLs have expired, calling this endpoint will refresh
+      # them. Similarly, in the event a previous account holder document upload has
+      # failed, you can use this endpoint to get a new upload URL for the failed image
+      # upload.
       #
-      #   When a new document upload is generated for a failed attempt, the response will
-      #   show an additional entry in the `required_document_uploads` list in a `PENDING`
-      #   state for the corresponding `image_type`.
+      # When a new document upload is generated for a failed attempt, the response will
+      # show an additional entry in the `required_document_uploads` list in a `PENDING`
+      # state for the corresponding `image_type`.
       #
       # @overload list_documents(account_holder_token, request_options: {})
       #
@@ -179,19 +179,19 @@ module Lithic
       end
 
       # Check the status of an account holder document upload, or retrieve the upload
-      #   URLs to process your image uploads.
+      # URLs to process your image uploads.
       #
-      #   Note that this is not equivalent to checking the status of the KYC evaluation
-      #   overall (a document may be successfully uploaded but not be sufficient for KYC
-      #   to pass).
+      # Note that this is not equivalent to checking the status of the KYC evaluation
+      # overall (a document may be successfully uploaded but not be sufficient for KYC
+      # to pass).
       #
-      #   In the event your upload URLs have expired, calling this endpoint will refresh
-      #   them. Similarly, in the event a document upload has failed, you can use this
-      #   endpoint to get a new upload URL for the failed image upload.
+      # In the event your upload URLs have expired, calling this endpoint will refresh
+      # them. Similarly, in the event a document upload has failed, you can use this
+      # endpoint to get a new upload URL for the failed image upload.
       #
-      #   When a new account holder document upload is generated for a failed attempt, the
-      #   response will show an additional entry in the `required_document_uploads` array
-      #   in a `PENDING` state for the corresponding `image_type`.
+      # When a new account holder document upload is generated for a failed attempt, the
+      # response will show an additional entry in the `required_document_uploads` array
+      # in a `PENDING` state for the corresponding `image_type`.
       #
       # @overload retrieve_document(document_token, account_holder_token:, request_options: {})
       #
@@ -242,7 +242,7 @@ module Lithic
       end
 
       # Simulates an enrollment review for an account holder. This endpoint is only
-      #   applicable for workflows that may required intervention such as `KYB_BASIC`.
+      # applicable for workflows that may required intervention such as `KYB_BASIC`.
       #
       # @overload simulate_enrollment_review(account_holder_token: nil, status: nil, status_reasons: nil, request_options: {})
       #
@@ -266,23 +266,23 @@ module Lithic
       end
 
       # Use this endpoint to identify which type of supported government-issued
-      #   documentation you will upload for further verification. It will return two URLs
-      #   to upload your document images to - one for the front image and one for the back
-      #   image.
+      # documentation you will upload for further verification. It will return two URLs
+      # to upload your document images to - one for the front image and one for the back
+      # image.
       #
-      #   This endpoint is only valid for evaluations in a `PENDING_DOCUMENT` state.
+      # This endpoint is only valid for evaluations in a `PENDING_DOCUMENT` state.
       #
-      #   Uploaded images must either be a `jpg` or `png` file, and each must be less than
-      #   15 MiB. Once both required uploads have been successfully completed, your
-      #   document will be run through KYC verification.
+      # Uploaded images must either be a `jpg` or `png` file, and each must be less than
+      # 15 MiB. Once both required uploads have been successfully completed, your
+      # document will be run through KYC verification.
       #
-      #   If you have registered a webhook, you will receive evaluation updates for any
-      #   document submission evaluations, as well as for any failed document uploads.
+      # If you have registered a webhook, you will receive evaluation updates for any
+      # document submission evaluations, as well as for any failed document uploads.
       #
-      #   Two document submission attempts are permitted via this endpoint before a
-      #   `REJECTED` status is returned and the account creation process is ended.
-      #   Currently only one type of account holder document is supported per KYC
-      #   verification.
+      # Two document submission attempts are permitted via this endpoint before a
+      # `REJECTED` status is returned and the account creation process is ended.
+      # Currently only one type of account holder document is supported per KYC
+      # verification.
       #
       # @overload upload_document(account_holder_token, document_type:, entity_token:, request_options: {})
       #

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.transform_keys(begin_: :begin, end_: :end),
+          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: {})
           #
@@ -46,7 +46,7 @@ module Lithic
             @client.request(
               method: :post,
               path: ["v2/auth_rules/%1$s/backtests", auth_rule_token],
-              body: parsed.transform_keys(end_: :end),
+              body: parsed,
               model: Lithic::Models::AuthRules::V2::BacktestCreateResponse,
               options: 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.transform_keys(begin_: :begin, end_: :end),
+          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.transform_keys(begin_: :begin, end_: :end),
+            query: parsed.transform_keys(begin_: "begin", end_: "end"),
             page: Lithic::Internal::SinglePage,
             model: Lithic::Models::FinancialTransaction,
             options: options