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

frontend_mariana opened this thread · · 2 replies

curp-validationregistration-uxform-designfrontend

Question

M
frontend_mariana Asker

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 debate on our team is when to trigger the CURP registration validation — should we call the API on blur (when user leaves the field), on submit (when they complete the whole form), or something 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. The API responds in about 300ms. 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

J
ux_dev_jorge

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 during the 300ms API call, 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.

D
mobile_dev_mx

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. Takes about 500ms total including API response and animation.

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.

● Thread open · 2 replies

Find API Providers on apipull.com