Skip to main content
OrigoID never returns opaque errors. Every error includes:
  • A stable type code that does not change between versions
  • A human message describing what happened
  • An actionable path to resolution

​
Common error types

​
Endpoint-specific result codes

Each endpoint can return additional type codes that represent valid business results (not errors per se). For example:
  • CURP endpoints can return CURP_NOT_FOUND, CURP_APOCRYPHAL, CURP_DECEASED
  • SAT endpoints can return CFDI_CANCELED, TAX_PROFILE_NOT_FOUND
  • Voter ID endpoints can return INE_NOT_FOUND, INE_NOT_VALID
  • Biometric endpoints can return FACE_MISMATCH, MASK_ATTACK
The complete list of type codes for each endpoint is documented in that endpoint’s page in the API reference. Treat business results according to your domain logic.

​
Validation error codes

When type is INVALID_REQUEST, the errors[] array lists field-level failures (see ErrorDetail). Each entry has a code you can branch on. These codes are cross-cutting — they may appear on any endpoint when the corresponding validation fails:

​
Endpoint-specific codes

Some endpoints add extra codes that capture domain-specific validation. For example:
  • INVALID_RFC_FORMAT (/mex/fiscal/v1/rfc-validations, SAT 69 / 69-B searches)
  • NAME_TOO_SHORT, NAME_ONLY_STOPWORDS (SAT 69 / 69-B searches)
  • QR_NOT_FOUND (/mex/fiscal/v1/csf-extractions, /mex/fiscal/v1/cfdi-validations)
  • IMAGE_UNREADABLE (OCR endpoints)
See each operation’s page in the API reference for the full list.

​
How errors aggregate

Multiple field-level validation failures in the same request may come back together in errors[]. The array length depends on which kind of validation failed:
  • Failures detected by request-shape validation (missing required fields, wrong types, bad patterns, enum / length / range mismatches) are aggregated — all violations of this kind come back in one response.
  • Failures detected by domain-specific checks (e.g. INVALID_RFC_FORMAT, NAME_TOO_SHORT, QR_NOT_FOUND) may return only the first error encountered, even if other fields would also have failed.
Always iterate errors[] rather than assuming a single entry. If your code receives one error, fixes it, and resubmits, the next response may surface additional errors that were latent.

​
Reporting an issue

If you hit an unexpected error, email support@origoid.com with:
  • The transactionId from the response
  • A brief description of what you were trying to do
  • The endpoint you called
We do not log request or response bodies, so we cannot retrieve your call automatically. When reporting, please include the transactionId and the path you called, and we will work with you on next steps.