Mexico Multiple Immigration Form (FMM) — Electronic, Land Entry

Entry Information

• meansOfEntry enum required

  How the applicant will enter Mexico. This document models only the land ('Terrestre') pathway: on the live wizard this field is pre-selected to 'By land' and its native HTML `` is disabled the moment the applicant accepts the terms checkbox under the page's single 'By Land' accordion panel — the wizard's own client-side script (`viaInternacion = "terrestre"`, hardcoded) never lets a user reach the alternative 'By air' ('Aéreo') value through this URL, even though that value, and the associated airline-name/flight-number fields, still exist in the underlying catalog and DOM. See VERIFICATION.md.

  enum: land

  pointOfEntry enum required

  The specific land border crossing point. Official Spanish names as published in INM's own point-of-entry catalog for land entry (60 values); the English UI renders these same Spanish place names untranslated, since they are proper nouns.

  enum: 60 values

  arrivalDate date required

  The live form displays this as a masked dd/mm/yyyy text input; represent as an ISO 8601 full-date. The live wizard's own client-side validation rejects an arrival date earlier than today or later than 29 days from today (i.e. the wizard may only be completed up to 30 days before arrival, inclusive of today).

  departureDate date required

  The live form displays this as a masked dd/mm/yyyy text input; represent as an ISO 8601 full-date. Must not be earlier than arrivalDate, and the live wizard's own client-side validation additionally rejects a departure date more than 179 days after arrivalDate (i.e. a maximum 180-day stay counting the arrival day) — only the first (chronological ordering) half of this rule is expressed in this document's crossFieldValidation; the 180-day cap has no offset-arithmetic operator in the GovSchema Condition grammar and is recorded here as prose instead.

  Personal Information

  • givenNames string required

    As shown on the travel document used to enter Mexico. The live form applies an ICAO-style name pattern (letters plus space/hyphen/apostrophe/period/comma separators, no digits) and converts to upper case.

    length: 1–100classification: pii
  • surname string required

    As shown on the travel document used to enter Mexico. Same ICAO-style name pattern as givenNames.

    length: 1–100classification: pii
  • gender enum required

    Gender

    enum: male | femaleclassification: pii
  • dateOfBirth date required

    The live form displays this as a masked dd/mm/yyyy text input; represent as an ISO 8601 full-date. The live wizard's own client-side validation rejects a birth date more than ~110 years (40,177 days) before today, or later than today. The wizard also derives the applicant's age at arrivalDate from this field to (a) decide whether the guardian section (see applicantIsMinor) is required, and (b) remove 'Business' from reasonOfTrip's options when the applicant will be under 2 years old at arrival — neither derivation is itself a field on the live form; see applicantIsMinor and reasonOfTrip.

    classification: sensitive-pii
  • nationality string required

    ISO 3166-1 alpha-2 country code. Drawn from INM's own closed country catalog (243 entries — the same catalog used for countryOfBirth/documentIssuingCountry/countryOfResidence, minus Mexico, which this specific field's option list excludes since the FMM is only completed by non-Mexican-national visitors). Not enumerated here given its size; see VERIFICATION.md for how the live catalog's opaque internal numeric IDs relate to this ISO code.

    patternclassification: pii
  • countryOfBirth string required

    ISO 3166-1 alpha-2 country code. Drawn from INM's full 244-entry country catalog (includes Mexico, unlike nationality — a person born in Mexico can hold only a foreign nationality and still use this form). Not enumerated here given its size; see VERIFICATION.md.

    patternclassification: pii

  Identification Document

  • documentType enum required

    Type of document

    enum: passport | passport_card
  • documentNumber string required

    Document number

    patternlength: 0–15classification: sensitive-pii
  • documentNumberConfirmation string required

    Must exactly match documentNumber. The live form disables copy/paste into this field to force the applicant to retype it.

    patternlength: 0–15classification: sensitive-pii
  • documentIssuingCountry string required

    ISO 3166-1 alpha-2 country code. Same 244-entry country catalog as countryOfBirth. Not enumerated here given its size; see VERIFICATION.md.

    pattern
  • documentIssueDate date required

    The live form displays this as a masked dd/mm/yyyy text input; represent as an ISO 8601 full-date. The live wizard's own client-side validation rejects an issue date earlier than dateOfBirth.

  • documentIssueDateConfirmation date required

    Must exactly match documentIssueDate. The live form disables copy/paste into this field.

  • documentExpiryDate date required

    The live form displays this as a masked dd/mm/yyyy text input; represent as an ISO 8601 full-date. The live wizard's own client-side validation rejects an expiry date earlier than today, and additionally requires it to be at least 179 days after arrivalDate (i.e. the travel document must remain valid through the maximum possible 180-day stay) — the latter offset rule is recorded here as prose only; see departureDate for the same offset-arithmetic limitation.

  • documentExpiryDateConfirmation date required

    Must exactly match documentExpiryDate. The live form disables copy/paste into this field.

  Place of Residence

  • countryOfResidence string required

    ISO 3166-1 alpha-2 country code. Same 244-entry country catalog as countryOfBirth. Not enumerated here given its size; see VERIFICATION.md.

    patternclassification: pii
  • residenceAddress string required

    Free text; the live form restricts this to upper-case letters, digits, and a small punctuation set ( . , " ' and hyphen), and converts to upper case.

    patternlength: 0–40classification: pii

  Trip Information

  • reasonOfTrip enum required

    Top-level reason category. The live catalog also defines a fourth top-level value, 'Crew' ('Tripulación'), but the wizard's own script removes it from this field's option list whenever means of entry is land (utils.filtraCatalogosPorClave / motivoEstanciaSinTripulacion) — since this document is scoped to land entry, 'crew' is never a reachable value here and is omitted. The wizard additionally removes 'Business' from the option list whenever the applicant will be under 2 years old at arrivalDate; this document does not encode that narrower, age-conditional exclusion (see dateOfBirth), since GovSchema's flat field/Condition model has no mechanism for conditionally shrinking an enum's value set based on another field.

    enum: tourism | business | other
  • reasonOfTripSpecify enum required

    The specific sub-reason. On the live form the option list populates dynamically based on reasonOfTrip (9 business sub-reasons, 5 other sub-reasons, 1 tourism sub-reason — 'crew' sub-reasons are excluded here for the same land-entry reason as reasonOfTrip); this field is unconditionally required regardless of which reasonOfTrip value is chosen, since every reachable top-level reason has at least one sub-reason. 'resident' has no official English translation on the live source (the English UI falls back to the Spanish label 'Residente'); 'artist_and_sportsman' preserves the live source's own English translation text verbatim, including its own apparent spelling ('Sportman' rather than 'Sportsman').

    enum: 15 values
  • destinationState enum required

    The Mexican state of destination. Official Spanish state names as published in INM's own catalog (32 entries, including Ciudad de México and Estado de México as distinct entries); the English UI renders these same Spanish names untranslated.

    enum: 32 values
  • addressInMexico string required

    Free text (e.g. hotel name, street, and number). Same upper-case letters/digits/limited-punctuation restriction as residenceAddress.

    patternlength: 0–40classification: pii

  Guardian Information

  • applicantIsMinor boolean required

    Derived field, not itself present on the live form: the wizard computes the applicant's age from dateOfBirth as of arrivalDate and shows/requires the guardian section below whenever that computed age is under 18. GovSchema's flat field/Condition model has no built-in date-arithmetic operator, so this document introduces this boolean as the explicit gate the live computation performs, following the same pattern the spec's own worked example uses for a plain yes/no gate (SPEC.md §6.7's isLLC). Set it to true only when the applicant will genuinely be under 18 on arrivalDate. See VERIFICATION.md.

  • guardianGivenNames string

    Name(s) of the accompanying father, mother, or legal guardian. Required only when applicantIsMinor is true.

    length: 1–100classification: pii
  • guardianSurname string

    Required only when applicantIsMinor is true.

    length: 1–100classification: pii
  • guardianGender enum

    Required only when applicantIsMinor is true.

    enum: male | female
  • guardianDateOfBirth date

    Required only when applicantIsMinor is true. The live wizard separately requires the guardian to be an adult (its own age computation on this same field, mirroring dateOfBirth/applicantIsMinor); not re-derived as a second synthetic field here — see VERIFICATION.md.

    classification: sensitive-pii
  • guardianNationality string

    ISO 3166-1 alpha-2 country code, same 244-entry catalog as countryOfBirth. Required only when applicantIsMinor is true.

    patternclassification: pii
  • guardianCountryOfBirth string

    ISO 3166-1 alpha-2 country code, same 244-entry catalog as countryOfBirth. Required only when applicantIsMinor is true.

    patternclassification: pii

  Email

  • email string required

    Used to send the folio/confirmation and, on final submission, a verification code. The live form converts input to lower case.

    patternclassification: pii
  • emailConfirmation string required

    Must exactly match email. The live form disables copy/paste into this field.

    patternclassification: pii

  Verification record

  This file is the source-review record for this document version, per the manual-source-review-v1 practice.

  Current claim

  • status: draft
  • verification.method: manual-source-review-v1
  • verification.lastVerifiedAt: 2026-07-06

  The document was derived from a directly-read live source: the Instituto Nacional de Migración's (INM) own Forma Migratoria Múltiple (FMM) electronic wizard, read field-by-field from the live DOM plus its own unminified client-side validation source code. It remains draft, not verified, pending an independent second reviewer's field-by-field pass.

  Why this document exists

  This cycle (GOV-1393, the recurring GovSchema Standard Research routine) scouted Mexico as a new-jurisdiction candidate — CATALOG.md's "Known Gaps & Opportunities" section had explicitly flagged Mexico, alongside an EU member beyond DE/FR/NL, as worth scouting once South Korea, the UAE, and Brazil had each been opened in recent cycles. Four Mexican verticals were scouted:

  • SRE passport — in-person appointment booking only, no field-level online form. Skipped.
  • SAT RFC (tax/business registration) — the official "Ficha 43/CFF" PDF is a document-requirements checklist, not a field-by-field form; the live SAT preinscription wizard returned HTTP 403 to a direct fetch (untested via a real browser this cycle — a candidate for a future cycle). Skipped.
  • CURP (national ID) — requires an in-person biometric appointment. Skipped.
  • INM FMM (this document) — strong candidate. A genuinely live, unauthenticated wizard with no login and no CAPTCHA gate ahead of the final save action.

  This opens Mexico as the registry's 16th jurisdiction, in the Visa vertical, matching the "open with the strongest single vertical first" pattern used for South Korea (GOV-1289), the UAE (GOV-1297/GOV-1335), and Brazil (GOV-1296/GOV-1342).

  Source examined

  • Document (id, version): mx/inm/forma-migratoria-multiple-electronica / 1.0.0
  • Spec version: GovSchema 0.3.0
  • Authority: Instituto Nacional de Migración (INM)
  • Primary source URLs:
    • English: https://www.inm.gob.mx/fmme/publico/en/solicitud.html
    • Spanish (default locale): https://www.inm.gob.mx/fmme/publico/solicitud.html — note this is not .../publico/es/solicitud.html. INM's en/ja/cn/ko variants each have their own path segment, but Spanish is served at the bare .../publico/ path with no es segment; .../publico/es/solicitud.html returns a genuine 404 (confirmed both via curl and via a real headless browser navigation, so this is not a bot-blocking artifact). The background research brief for this cycle had assumed a .../es/ path by analogy with the other locales; this was corrected during extraction.
    • Field-option catalog (both locales' dropdowns are populated from this): https://www.inm.gob.mx/fmme/resources/solicitud/meta-resources/catalogos?lang=en (and ?lang=es) — an XML document, despite the URL's JSON-suggestive path segment (meta-resources).
  • Retrieved / reviewed: 2026-07-06
  • Reviewer: GovSchema Engineering (initial authoring source-review)

  Extraction method

  1. Rendered both .../en/solicitud.html and .../publico/solicitud.html (Spanish) with a headless Chromium (Playwright-core, per [[browser-screenshots-setup]]) at 1366×1400/1600. No login, no redirect, no CAPTCHA blocks the page itself.
  2. The page ships all field markup for every section in a single initial page load (an "accordion" with a single panel labelled "By Land" in English / "Terrestre" in Spanish) — checking its terms-acceptance checkbox reveals the full form via slideDown(), not a fresh page fetch. Ran document.querySelectorAll('input, select, textarea') and recorded every element's id, native type, and (crucially) discovered that every native HTML validation attribute (required, pattern, maxlength) is unset on every field — this site enforces its own required/format rules entirely through a custom jQuery validation object attached via $(el).configura({...}), not through native HTML5 form validation.
  3. Because of finding 2, DOM inspection alone would have under-reported required-ness and pattern constraints for nearly every field. This document's field-level required/validation claims are instead sourced directly from the wizard's own unminified client-side JavaScript, fetched directly (no login needed — these are plain static assets):
     • https://www.inm.gob.mx/fmme/js/jquery.inm.fmme.solicitud-1.0.0.js — the FMM-specific controller: which fields are required by default, which become required only conditionally (the guardian block; the airline/ flight-number pair for air entry), the exact 30-day arrival window / 180- day maximum stay / passport-must-outlast-stay date rules, the minor/ guardian age computation, and the catalog-filtering logic (see below).
     • https://www.inm.gob.mx/util/js/jquery.inm.common.validator-3.1.4.js — the shared validator: the default per-type required/maxlength/ pattern values (e.g. every untyped text input defaults to maxlength: 40, pattern: /^[A-Za-z0-9 ]+$/, required true, unless a later .configura() call overrides it — which is how direccionResidencia/ domicilioMexico keep maxlength: 40 but get a custom punctuation- inclusive pattern), the email/date/nombre-icao type patterns, and the confirmation-field equality checks.
  4. Fetched the catalog endpoint directly (?lang=en and ?lang=es) and parsed the XML to get every dropdown's full, exact option set: 244 countries (with ISO alpha-2/alpha-3 codes), 32 Mexican states, 60 land points of entry, 38 air points of entry (unused — see Out of scope), 20 reason-of-trip entries (4 top-level + 16 sub-reasons), 2 genders, 2 document types, 2 means-of-entry values.
  5. Ran a full interactive dry run against the live wizard with fabricated data (see Mock-data conformance check below): filled every field with valid mock values, triggered every confirmation-mismatch case one at a time to capture the live wizard's own error text, and set a birth date making the applicant a minor to confirm the guardian section's exact trigger and field set. Never clicked the final "confirmar" action that would actually POST to /fmme/resources/solicitud/ — this is a read-only verification exercise, not a real transaction, per GOVERNANCE.md.

  What was confirmed directly (verbatim, from the live DOM/JS/catalog)

  • Every field's id, section grouping (Entry Information / Personal information / Identification document / Place of residence / Trip information / Father, mother or guardian information / Email), and English + Spanish label text.
  • Every dropdown's full, exact option set (see step 4 above) — none paraphrased or truncated internally; the two very large ones (244 countries, described in nationality/countryOfBirth/etc.) are cited as a closed catalog rather than enumerated in the schema, per this registry's existing convention for oversized enumerations (see us/cbp/esta-application's countryOfBirth/nationality fields, which use the same "ISO 3166-1 alpha-2, not enumerated" pattern).
  • The exact required/optional/conditionally-required status of every field (from the validator source, not the native DOM attributes — see Extraction method step 2-3).
  • The four confirmation-field-mismatch error strings ("Does not match with the number of the document." / "...issuing date." / "...expiration date." / "...email.") and the "Required" per-field error, all captured live by triggering each condition.
  • The guardian ("Father, mother or guardian information") section's exact trigger (utils.validaMenorEdad(): applicant's age at arrivalDate computed from dateOfBirth is under 18) and its exact field set (6 fields, all becoming visible and required together) — confirmed live by setting a birth date yielding age 10 and screenshotting the revealed section.
  • The reasonOfTrip under-2-years business exclusion: confirmed live by setting a birth date yielding an applicant under 2 years old at arrival and observing motivoViaje's option list shrink to Tourism/Other only (Business removed) — utils.cargaMotivosViaje2anios().

  Interpretive judgment calls flagged for an independent reviewer

  1. Land-entry-only scope, and why "by air" is not modelled. The English background brief for this cycle assumed the wizard offered a real land/air/sea choice. On close inspection of the live page and its controller script, this specific URL's single accordion panel is permanently labelled "By Land"/"Terrestre", and the moment the terms checkbox is accepted, the controller runs viaInternacion = "terrestre"; utils.cambiaViaInternacion(); unconditionally — this filters the #internacion (meansOfEntry) <select> down to a single option and disables it. Confirmed live: after accepting terms, the rendered #internacion element has exactly two <option>s ("Select One" and "By land") and disabled === true; the "By air" value is not merely hidden, it is absent from the option list entirely. The underlying catalog (tiposFlujo) and the controller's own conditional logic (cargaCatalogoPuntosInternacion) still define an "aereo" pathway with an associated airline-name/flight-number pair and a 38-entry air point-of-entry catalog, but no URL or path found this cycle reaches it (no ?tipo=aereo-style parameter, no sibling solicitudAerea.html, no link to one from the FMM landing pages). Rather than model an unreachable branch as if it were live, this v1.0.0 document is deliberately scoped to the land-entry pathway only, with meansOfEntry modelled as a single-value enum (["land"]) rather than a real user choice. If a distinct air-entry INM wizard URL is found in a future cycle, it should become either a sibling document or a visibleWhen-gated extension of this one — flagged here rather than guessed at.
  2. applicantIsMinor is a synthetic field, not a source field. The live wizard computes "is the applicant a minor" from dateOfBirth and arrivalDate and uses that computed fact — never asked of the applicant directly — to gate the guardian section. GovSchema's v0.3 field/Condition model is flat and has no date-arithmetic operator (§16 of SPEC.md lists "Calculated / derived fields" as an explicitly deferred construct), so there is no way to express "age at arrival < 18" as a Condition over dateOfBirth and arrivalDate directly. This document introduces applicantIsMinor as an explicit boolean gate — the same pattern SPEC.md §6.7's own worked example uses for isLLC — and documents in the field's own description that it is derived, not itself a form field. A reviewer should confirm this is the right resolution versus, e.g., scoping the document to adults only (the precedent br/pf/passport-application took) — this cycle chose to model the minor pathway instead, since the task's own dry-run requirement explicitly called out exercising the conditional guardian section.
  3. The guardian-must-also-be-an-adult rule is not encoded as a second synthetic field. The live wizard raises an error ("The tutor must be of legal age.") if the guardian's own fechaNacimientoTutor also computes to under 18 at final submission — a second, independent age check (utils.validaTutorMayorEdad() / utils.mayorEdad()). Correction from an earlier draft of this note: this check shares the same utils.calculaEdad() helper the applicant's own validaMenorEdad() uses, and that helper is hardcoded to compute age against #fechaLlegada (arrivalDate) — its own source comment reads "respecto a la fecha de llegada" — with no code path that falls back to today's date; there is no date-of-comparison difference between the two checks after all. Introducing a second synthetic boolean here still felt like compounding an already-disclosed modelling gap rather than resolving it cleanly, so this rule remains recorded as prose in guardianDateOfBirth's description rather than a second applicantIsMinor-style field. Confirmed live by observing the error text with an empty fechaNacimientoTutor field (which fails the age check by producing a negative/invalid age), and confirmed directly against the live jquery.inm.fmme.solicitud-1.0.0.js source during independent re-verification (GOV-1397).
  4. Country fields modelled as ISO 3166-1 alpha-2, not the catalog's own opaque numeric IDs. The live form's actual submitted payload (solicitante.pais.id, etc., per utils.creaFmme()) references a country by an internal numeric catalog ID (e.g. 57 for the United States), not an ISO code — the ISO alpha-2/alpha-3 codes only exist as additional attributes (clave/iso3) on each catalog entry, not as the value the form transmits. This document models every country-valued field (nationality, countryOfBirth, documentIssuingCountry, countryOfResidence, guardianNationality, guardianCountryOfBirth) as the ISO 3166-1 alpha-2 code rather than the numeric ID, since alpha-2 is the internationally standard, jurisdiction-neutral encoding this registry's design principles call for (SPEC.md §3 principle 6) and is still recoverable from the same catalog (clave per entry). A consumer that needs to actually drive this specific live form would need to resolve alpha-2 → the current numeric ID via INM's own catalog endpoint at fill time, since the numeric IDs are an internal implementation detail with no external stability guarantee (unlike the ISO code).
  5. especifiqueMotivo's two non-standard-English values. resident (source clave otro/residente) has no English traduccion in the catalog at all — even under ?lang=en the entry is untranslated Spanish ("Residente"); this document supplies its own English slug. Separately, artist_and_sportsman (source clave otro/artista-deportista) preserves the catalog's own English translation text verbatim, including what reads as a source-side spelling choice ("Sportman" rather than "Sportsman") — kept as-is rather than silently "corrected", since GovSchema describes the source, it does not edit it.
  6. The 180-day-stay and passport-validity offset rules are prose, not crossFieldValidation. departureDate must be ≥ arrivalDate and ≤ arrivalDate + 179 days; documentExpiryDate must be ≥ arrivalDate + 179 days. Only the ≥ half of the first rule is expressible with the v0.3 Condition/crossFieldValidation grammar's compare operators (greaterThanOrEqual between two field values, encoded as departureNotBeforeArrival); the "+179 days" offset itself has no representation in a grammar whose leaf comparisons take another field's raw value, not an arithmetic transform of it (SPEC.md §16 lists relative/ calculated constraints as out of scope for v0.3). Both offset rules are recorded as descriptive prose on departureDate and documentExpiryDate instead of a (necessarily incomplete, and therefore misleading) crossFieldValidation entry.
  7. No documents[] entries. The FMM wizard itself collects no file uploads and states no fee amount on this page; a separate INM payment portal (inmex.html) is referenced only as after-the-fact guidance in the review-step copy, with no amount shown. Consistent with the br/pf/passport-application precedent for an unstated, separately-paid fee, this document leaves documents[] absent rather than guessing an amount or modelling a paymentless placeholder.
  8. steps reflect the wizard's own visual section headings on a single scrollable page, not a multi-tab flow. Unlike br/pf/passport-application's SINPA wizard (four real, separately-clicked tab panels), INM's FMM renders as one continuously-scrollable page with <h2>/<h3> section headings and a single "Save" (procesar) button at the bottom. steps is still used here, matching this registry's general convention of grouping fields for presentation, but a reviewer should read steps[].next as "the next section on the same page", not as a literal page transition the way it is for SINPA or most other multi-screen wizards in this registry.

  Mock-data conformance check (Phase 4)

  A fabricated, non-submitting mock application packet lives at conformance/mx/inm/forma-migratoria-multiple-electronica/1.0.0/application-packet.json (+ .txt rendering): a fictitious US tourist, adult, entering by land at "El Chaparral" bound for Baja California. This exact data set was entered into the live wizard field-by-field (see Extraction method step 5): the wizard's own client-side validation accepted it in full, and clicking "Save" (procesar) produced zero validation errors other than the empty CAPTCHA verification-code field (which this document does not model — see the top-level description). Variants were then run one field-change at a time directly against the live wizard (not a local reimplementation) to confirm each rule this document claims:

  • Mismatched documentNumberConfirmation → live error "Does not match with the number of the document."
  • Mismatched documentIssueDateConfirmation → live error "Does not match with the issuing date."
  • Mismatched documentExpiryDateConfirmation → live error "Does not match with the expiration date."
  • Mismatched emailConfirmation → live error "Does not match with the email."
  • Birth date yielding age 10 at arrival → guardian section appears, its six fields become required (empty birth date → "The tutor must be of legal age." error, confirming rule 3 above).
  • Birth date yielding age under 2 at arrival → reasonOfTrip's live option list drops to Tourism/Other only.

  This document was not submitted to inm.gob.mx or any other live system at any point — the final "confirmar" POST action was never invoked, per GOVERNANCE.md.

  What is out of scope for v1.0.0

  • Air and sea entry — see judgment call 1 above.
  • The CAPTCHA/verification-code step and final submission — this document ends at the point the live wizard itself reaches a client-side-valid, ready-to-save state; the CAPTCHA image/code pair and the POST to /fmme/resources/solicitud/ are excluded by design (per AGENTS.md and GOVERNANCE.md, GovSchema never submits on anyone's behalf).
  • Fee payment — see judgment call 7 above.
  • The post-save PDF download and folio/tracking-number retrieval flow — these happen only after a real submission and are not part of the data-entry wizard this document models.
  • Mexico's other four verticals (Passport, DMV, Business Formation/Tax, National ID) — all scouted this cycle and found weak or gated for now (see "Why this document exists" above); left as open backlog candidates for a future cycle, not dead ends. SAT's live preinscription wizard in particular (403 to a direct fetch) is worth a real-browser retry.

  Path to a verified claim (next step)

  To advance this document to status: verified, a reviewer needs to independently re-render the same live FMM wizard (both language variants), re-check every sourceRef and validator-derived constraint against the live JS source directly (not just the rendered DOM, which under-reports constraints — see Extraction method step 2), re-confirm the land-only entry scope is still accurate, and confirm no newer wizard revision has changed the field set or catalog.

  Re-verification

  Per the practice's Cadence, nextReviewBy is set to 2027-01-06 (~6 months): this is the registry's first Mexican document and the first document in this registry sourced by direct client-side-validator-source inspection (rather than pure DOM/PDF/screenshot extraction), so the shorter end of the cadence is appropriate until the technique and the land-only scope boundary are independently confirmed. Re-check the source, and confirm no newer wizard revision has been published, on or before that date and on any source.url change.

  View the raw record (VERIFICATION.md)

  Version history

  • 1.0.0 draft latest this page has verification record schema.json

  Related schemas

  Same process in other jurisdictions

  • ae/icp/visa-single-entry-long-stay-pleasure
  • am/mfa/evisa-application
  • ar/cancilleria/formulario-solicitud-visado
  • at/bmeia/schengen-visa-application
  • au/homeaffairs/eta-application-601
  • bd/dip/machine-readable-visa-application-form

  + 90 more

  All immigration and residency schemas →

  Independent and non-affiliated

  GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Instituto Nacional de Migración or any government. The authoritative source is always the live government form and its official instructions.