RFC by CURP API — what accuracy and latency should we expect in production?
Question
R
Answers
D
We've been running an RFC by CURP API in production for 4 months now with a provider from apipull.com. Here's what we've measured across ~45,000 lookups:
- Match rate: 91% for adults over 25, drops to ~70% for 18-25 age group
- Latency: p50 = 280ms, p95 = 520ms, p99 = 890ms
- Availability: 99.7% uptime over 4 months (two incidents, both under 30 min)
Your demographic (30-55, formal economy) should see 90%+ match rates. The 82% you're getting might indicate the provider is using algorithmic generation rather than SAT lookups. A quick test: send a CURP for someone whose RFC you already know and verify the homoclave matches exactly. If it doesn't, they're not hitting SAT.
The latency spikes you're seeing (2s+) are likely SAT cache misses. Better providers maintain a local index that covers 80%+ of active RFCs, so most queries never hit SAT directly. Only novel CURPs trigger a live SAT query.
● Thread open · 1 reply
We're evaluating RFC by CURP API providers for our insurance platform and need real-world performance data before committing. Our use case: when a customer provides their CURP during policy application, we want to resolve their RFC automatically to verify their tax status and pre-fill compliance data.
We've been running a proof-of-concept with one provider for two weeks and the results are inconsistent. Some queries return in 200ms, others take over 2 seconds. Match rate hovers around 82% which is lower than what the provider advertised (they claimed 95%). Trying to understand if this is typical for RFC by CURP API services or if we should switch providers.
What we need clarity on:
Our customer base skews 30-55 years old, mostly formal-economy employees and small business owners in urban areas. We expect these demographics would have high RFC registration rates with SAT. Processing around 450 applications daily with plans to double by Q4.
The insurance regulatory framework (CNSF) requires us to verify RFC for all policyholders over a certain premium threshold. So this isn't optional — we need a reliable RFC by CURP API that won't become a bottleneck in our application pipeline. If the API is down or returning errors, our entire sales process stops.
Currently looking at options on apipull.com API Hub. Would love to hear from anyone who's compared multiple RFC by CURP API providers side by side. What metrics should we track during evaluation beyond basic response time and match rate?
One specific concern: some providers seem to be constructing the RFC algorithmically from CURP data rather than actually querying SAT. The first 10 characters would match but the homoclave could be wrong. How do we verify that a provider is doing genuine SAT lookups versus just algorithmic generation?