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.

A webhook endpoint that returns no successful (2xx/3xx) response over a sustained period while failed deliveries keep accumulating is now switched off instead of retried indefinitely. A brief outage or a few scattered errors does not qualify, and endpoints where only some event types fail are left alone.

We warn first: the account owner, and the alerts email set in the Dashboard when there is one, gets an email naming the failing endpoints, and the endpoint is only disabled if it is still failing several days later. Events that occur while it is disabled are not delivered and are not replayed afterwards, so fetch anything you missed through the API.

You can re-enable an endpoint at any time under Development → Webhooks in the Dashboard, or by sending {"enabled": true} to the Update webhook endpoint. The enabled flag is also returned when listing webhooks.

See the Update a webhook reference.

Loan application number: The loan object on an order now accepts an application_number (the POS file number) as an alternative to loan_number. A loan must supply at least one of the two identifiers; loan_number is no longer required on its own. The new field is returned in the loan object on order create, retrieve, and list responses, so if you validate responses against a strict schema, update it to allow application_number.

This supports POS-first workflows where the file exists before the LOS has assigned a loan number. If you currently send a placeholder in loan_number, we recommend moving that value to application_number and populating loan_number only once the real one is assigned. In the near future, loan_number will no longer be editable once set, and attempts to change it will be rejected. That change will be announced separately.

See the Loan object reference for the full loan schema.

Provider category field: We're adding a new category field to the Data Provider object that classifies each provider by the type of income it represents: w2 for traditional W-2 payroll employers, gig for gig-economy platforms, and benefits for government benefits providers.

The field will be returned by the List providers (GET /v1/providers/) and Retrieve provider (GET /v1/providers/{id}/) endpoints starting August 6, 2026. This is an additive change and requires no action for most integrations. If you validate API responses against a strict schema, update it to allow the new category field before then.

See the Data Provider object reference for the full schema.

List orders endpoint: You can now retrieve a paginated list of your orders with the new List orders endpoint (GET /v1/orders/).

The endpoint uses cursor-based pagination and supports filtering by date range, status, product, source, and more, plus full-text search across fields like order number, loan number, and applicant name. This lets you pull orders in bulk without knowing individual order IDs.

See the List orders API reference for the full request and response schema.