📉 Net income estimates and no per-identifier daily limit

• 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 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.