Should we validate CURP on blur or on form submit? UX patterns for registration

Published

curp-validationregistration-uxform-designfrontend

Question

Question

Working on a registration form redesign for our telecom app. We added CURP as a required field for account creation (regulatory requirement for SIM registration in Mexico). The open design question is when to trigger CURP registration validation — on blur (when the user leaves the field), on submit (when the whole form is complete), or somewhere in between.

Our current implementation validates on submit. The problem: users fill out the entire form (name, email, phone, address, CURP), hit submit, and then get an error saying their CURP is invalid. They have to scroll back up, fix it, and resubmit. Our analytics show a 35% form abandonment rate at this point — users just give up.

I want to validate on blur so users get immediate feedback. But my backend team is concerned about API costs — if users are tabbing through the form and trigger multiple validations on partial input, we'd be burning API calls. A CURP field with 18 characters means users might trigger blur multiple times while editing.

Options we're considering:

  • Validate on blur — immediate feedback, but might trigger on incomplete input
  • Validate on blur + debounce — wait 800ms after last keystroke, only validate if field has 18 chars
  • Validate on blur + format check first — do local regex validation, only call API if format is valid
  • Validate on submit only — current approach, poor UX
  • Progressive validation — format check client-side, API check on submit, but show partial feedback during typing

Additionally, if validation succeeds, we want to auto-fill the name fields with data from the CURP API response. This creates a nice "verified" experience where the user sees their legal name appear automatically. But what if the auto-filled name doesn't match what they already typed? Do we overwrite their input or show a mismatch warning?

Our stack: React (Next.js) frontend, CURP API from a third-party provider. Response time varies by upstream source and query type, so treat it as variable rather than fixed. We're processing roughly 2,000 registrations per day. Need this to work well on both desktop and mobile (60% of our traffic is mobile).

Would love to see code examples or hear about A/B test results from anyone who's solved CURP registration validation UX in a consumer app. What worked best for your users?

Answers

Answer

Validate on blur after the CURP field, but only if the input is exactly 18 characters and passes a local format regex first. This eliminates wasted API calls on partial input. Users get instant feedback and you can auto-fill subsequent fields (name, DOB, gender).

We A/B tested this against submit-only validation. Results: 23% fewer form abandonments with blur validation. The auto-fill is key — users feel like the form is doing work for them instead of creating work. We put a small spinner on the CURP field while the API call is in flight, then show a green checkmark and auto-populate name fields below.

For the name mismatch scenario: we show the API-returned name in the name fields with a subtle "verified via RENAPO" badge. If the user had already typed something different, we replace it but show a tooltip saying "Name updated to match official records." Never had complaints about this.

Answer

On mobile, validate after the 18th character is typed — no need to wait for blur since you know the exact length. Show a green checkmark inline and auto-advance focus to the next field. Feels magical to users. We got this pattern from a provider integration guide on apipull.com API Hub.

Code-wise it's simple: onChangeText handler checks value.length === 18, runs regex, then fires the API call. Show a loading indicator inside the input field (right-aligned spinner icon). On success, animate the checkmark in and auto-scroll to show the auto-filled fields below. The animation runs once the response arrives, so perceived duration tracks whatever the API call actually takes.

One edge case: if the API returns an error, don't clear the field. Show red border + error message but keep the input so the user can edit. If it's a "service unavailable" error, show "We'll verify this later" and let them proceed — don't block registration on a temporary outage.

More questions on this topic

These answers were consolidated from separate pages covering the same topic.

CURP to NSS API — convert CURP to social security number

In theory 1:1, but in practice duplicate NSS numbers exist for the same person from historical IMSS data issues. A good CURP to NSS API will flag when multiple records exist and return the primary one.

Duplicates are a known IMSS data quality issue. If found, the employee typically needs to visit IMSS to consolidate records. Your app should handle this edge case gracefully.

How to find NSS by CURP via API?

Third-party APIs can find NSS by CURP with employee consent. The consent flow is usually the employee accepting a privacy notice that covers IMSS data lookups — document it properly.

Sources

Find API Providers on apipull.com