we-promise/sure · error · Provider::Redbark::Error

bad_request

bad_request

Error message

Bad request: #{error_message_from(response)}

What it means

Raised by Provider::Redbark's handle_response on HTTP 400 from any Redbark endpoint. The message embeds error_message_from(response), which parses the Redbark error envelope ({ error: { message, code, details } }) and carries only the provider's message — never the raw body. Error type :bad_request.

Source

Thrown at app/models/provider/redbark.rb:238

    end

    def auth_headers
      {
        "Authorization" => "Bearer #{@api_key}",
        "Content-Type" => "application/json",
        "Accept" => "application/json"
      }
    end

    # Redbark error envelope: { error: { message, code, details } }
    # Error messages carry the parsed provider message only, never the raw
    # response body - callers log and re-log these strings.
    def handle_response(response)
      case response.code
      when 200, 201
        JSON.parse(response.body, symbolize_names: true)
      when 400
        raise Error.new("Bad request: #{error_message_from(response)}", :bad_request)
      when 401
        raise AuthenticationError.new("Invalid API key", :unauthorized)
      when 403
        raise AuthenticationError.new("Access forbidden - your Redbark plan may not include API access", :access_forbidden)
      when 404
        raise Error.new("Resource not found", :not_found)
      when 410
        raise Error.new("Endpoint requires an accountId: #{error_message_from(response)}", :bad_request)
      when 429
        raise RateLimitError.new("Rate limit exceeded", :rate_limited)
      when 500..599
        raise ServerError.new("Redbark server error (#{response.code})", :server_error)
      else
        raise Error.new("Unexpected response #{response.code}: #{error_message_from(response)}", :unknown)
      end
    end

    def error_message_from(response)

View on GitHub (pinned to e69894adb9)

Solutions

1. Read the provider message in the exception — it names the offending parameter
2. Verify connection_id/account_id values came from list_connections/list_accounts on the same API key
3. Ensure start_date/end_date are Date objects (the client calls to_s on them, producing YYYY-MM-DD)
4. Remove blank optional params instead of sending empty strings

Example fix

# before
redbark.get_transactions(connection_id: cid, account_id: aid, start_date: "06/30/2024", end_date: "12/31/2024")

# after
redbark.get_transactions(connection_id: cid, account_id: aid, start_date: Date.new(2024, 6, 30), end_date: Date.new(2024, 12, 31))

def valid_redbark_query?(connection_id:, account_id:, start_date: nil, end_date: nil)
  connection_id.to_s.match?(/\A\w+\z/) && !account_id.to_s.strip.empty? &&
    start_date.is_a?(Date) && end_date.is_a?(Date) && start_date <= end_date
end

def redbark_bad_request?(error)
  error.is_a?(Provider::Redbark::Error) && error.error_type == :bad_request
end

begin
  redbark.get_transactions(connection_id: cid, account_id: aid, start_date: from, end_date: to)
rescue Provider::Redbark::Error => e
  raise unless e.error_type == :bad_request
  Rails.logger.error("Redbark rejected params: #{e.message}") # message names the bad param
  raise
end

When it happens

Trigger: GET /transactions with a malformed from/to date (non-ISO string), an invalid connectionId/accountId format, or other invalid query parameters rejected by Redbark's validator.

Common situations: Passing Date/Time objects that stringify badly; copy-pasted stale ids; schema changes on Redbark's side rejecting previously-valid params; empty strings for optional params.

Related errors

• bad_request
• bad_request
• bad_request
• bad_request
• bad_request

AI-assisted analysis of we-promise/sure@e69894adb9 (2026-08-21). Data as JSON: /api/errors/1cbb60d5d99f3588. Report an issue: GitHub.