---
agentTools:
  projectIndex: https://developers.burodeingresos.com/llms.txt
---

# 📉 Net income estimates and no per-identifier daily limit

<br />

* **Removed** — the per-identifier daily verification cap is gone. You can now create as many verification attempts as you need for the same identifier; the `daily_verification_limit_exceeded` error is no longer returned, and bulk items no longer use `status_code=rate_limit_exceeded`. The only rate limit that remains is the global `rate_limit_exceeded` (120 requests per 60 seconds per account).
* **Improved** — `estimated_monthly_income` on `GET /profile/{identifier}` is now consistently an estimate of **net monthly income** (approximate take-home pay). Values for profiles whose income estimate comes from employment (social-security salary) data may decrease compared to before; purely invoice-based profiles are unchanged.

## ⚙️ What Changes

### Per-identifier daily limit removed

* Previously, each identifier (CURP or RFC) was limited to **2 verification attempts per day**. Further attempts returned a `429 daily_verification_limit_exceeded` error, and bulk requests could mark items as `status_code=rate_limit_exceeded`.
* That per-identifier cap has been removed. You can now retry as often as needed; only the global account-level limit of **120 requests per 60 seconds** remains, with the `rate_limit_exceeded` error.
* Historical bulk items that already carry `status_code=rate_limit_exceeded` keep that value, but new bulks will not produce it.

### `estimated_monthly_income` aligned to net income

* On `GET /profile/{identifier}`, `estimated_monthly_income` is now defined as an estimate of **net monthly income** (take-home pay), rather than a mix of gross and net depending on the underlying source.
* Profiles whose income is inferred from employment (social-security salary) data will typically see a lower value than before, because the estimate is closer to what the person actually receives. Purely invoice-based profiles are unchanged.
* The [Profile reference](https://developers.burodeingresos.com/docs/profile#estimated-monthly-income) has been updated to reflect this meaning; the field type and location in the response are unchanged.

## 🛠️ Action Recommended

* Remove any special handling of the `daily_verification_limit_exceeded` error and per-item `status_code=rate_limit_exceeded` in your integration; you will no longer see them on new traffic.
* If you currently retry verifications automatically (for example when `can_retry=true`), consider adding your own deduplication/backoff to avoid unnecessary repeated attempts, since there is no built-in daily cap anymore.
* Review any decision thresholds that use `estimated_monthly_income`, especially for profiles whose income comes from employment data, and adjust them if needed given that the values now approximate net income.