Changelog

Monetary values across the API are moving to a single representation: a decimal string with two decimal places, such as "2697.36". The majority of monetary fields already use this format. On September 25 2026, the remaining fields that currently return a JSON number switch to the same format, so every monetary value in the API is represented consistently.

Asset verification reports

Four fields change on GET /v1/users/{user_id}/assets/reports/{report_id}/ and POST /v1/users/{user_id}/assets/reports/:

• accounts[].balances.balance
• accounts[].balances.available_balance
• accounts[].balances.credit_limit
• accounts[].transactions[].ending_daily_balance

This also resolves an inconsistency within a single response. The same account balance was returned as a number under balances and as a decimal string under summary. Both now use the decimal string.

Before:

{
  "balances": {
    "currency_code": "USD",
    "balance": 2697.36,
    "available_balance": 1359.82,
    "credit_limit": null
  },
  "summary": {
    "currency_code": "USD",
    "balance": "2697.36"
  },
  "transactions": [
    {
      "amount": "0.61",
      "ending_daily_balance": 2697.36
    }
  ]
}

After:

{
  "balances": {
    "currency_code": "USD",
    "balance": "2697.36",
    "available_balance": "1359.82",
    "credit_limit": null
  },
  "summary": {
    "currency_code": "USD",
    "balance": "2697.36"
  },
  "transactions": [
    {
      "amount": "0.61",
      "ending_daily_balance": "2697.36"
    }
  ]
}

These fields continue to return null when a value is not available.

See the Balances object and Transactions object reference.

Scoring attributes reports

Two fields change on GET /v1/scoring_attributes/reports/{report_id}:

• derived_incomes[].average_amount
• derived_incomes[].monthly_amount

Before:

{
  "derived_incomes": [
    {
      "average_amount": 475.99,
      "monthly_amount": 1003.21
    }
  ]
}

After:

{
  "derived_incomes": [
    {
      "average_amount": "475.99",
      "monthly_amount": "1003.21"
    }
  ]
}

scores[].value and metrics[].value are not monetary values and are unchanged.

See the Scoring attributes object reference.

Direct deposit and paycheck linked lending reports

deposit_value is now always returned with two decimal places on:

• GET /v1/links/{link_id}/direct_deposit/report/
• GET /v1/links/{link_id}/pll/report/
• GET /v1/users/{user_id}/deposit_switch/report/

Before:

{
  "deposit_value": "25",
  "deposit_type": "percent",
  "is_confirmed": true
}

After:

{
  "deposit_value": "25.00",
  "deposit_type": "percent",
  "is_confirmed": true
}

The value itself does not change. Where deposit_type is percent, the field continues to express a percentage rather than an amount. deposit_value on the bank account object already used two decimal places and is unchanged.

See the Direct deposit report object reference.

Pay statement rates and units

rate and units on earnings are a pay rate and a quantity rather than monetary amounts, so they keep variable precision instead of moving to two decimal places. Values carrying more than six decimal places are now rounded to six. All other values are unchanged.

This affects earnings[] and earnings_ytd[] wherever pay statements are returned, including GET /v1/links/{link_id}/statements/, GET /v1/links/{link_id}/income/report/, and GET /v1/orders/{id}/.

Before:

{
  "name": "Regular",
  "amount": "1935.77",
  "rate": "17.0000",
  "units": "41.666666666666664"
}

After:

{
  "name": "Regular",
  "amount": "1935.77",
  "rate": "17.0000",
  "units": "41.666667"
}

See the Earnings object reference.

What is not changing

• Request bodies. Both 2500 and "2500" continue to be accepted wherever monetary values are sent. No changes are needed to code that creates orders, tasks, or reports.
• Field names, on every endpoint.
• null for values that are not available.
• The amounts themselves. Only their JSON representation changes.
• Every monetary field that already returns a decimal string, which is the majority of the API.

What to check in your integration

• Code that parses these fields as JSON numbers should parse decimal strings instead.
• Statically typed clients need the field type updated from a number or double to a string.
• In JavaScript, JSON.parse returns these fields as strings, so arithmetic on them needs an explicit conversion.