Registry entry

Mongolia Electronic Visa (e-Visa) Application

The Immigration Agency of Mongolia's Electronic Visa Application System, served unauthenticated at evisa.mn (immigration.gov.mn's own e-visa channel, live since 2021 under the Law on the Legal Status of Foreigners). The live wizard has four named parts: (1) Document type & Nationality (nationality, passport type, and an "applying for" purpose category, plus an email address); (2) Personal information (passport and biographic details, current-residence and emergency-contact details, an address-in-Mongolia block with a real cascading Province -> District/Soum -> Subdistrict/Bag selector, a facial-photo upload, an optional supporting-document upload, three yes/no declarations, and an accommodation-confirmation document-type selector); (3) Purpose & Duration (a fifteen-question supplementary declaration plus expected arrival/departure dates); and (4) Data confirmation (a terms-and-conditions attestation followed by payment). This schema models parts 1-3 in full plus the part-4 attestation. Reaching part 2 onward requires confirming a one-time emailed link (a genuine double-opt-in email-confirmation gate, not a CAPTCHA or biometric check) sent to the address entered in part 1; this session controlled a real disposable-inbox address for that purpose (no real applicant's identity or a real government-issued credential was used or impersonated). Every field name, required-asterisk marking, and dropdown option list documented here was read directly from the wizard's own live-rendered HTML (all four parts' markup is present in a single page load via the jquery.steps plugin, gated only by CSS visibility, not by separate page requests) after that link was followed, not inferred or guessed. This schema does NOT model: the Guardian-information sub-flow (b_/e_-prefixed fields), which the site's own client-side logic shows only when its passport-photo OCR reads an applicant date of birth indicating an age under 18 -- a real-time computed condition this registry's Condition grammar cannot express (it references only static field-to-field comparisons, not a computed age-from-date-of-birth threshold), and which this session could not otherwise trigger without a fabricated minor's passport image; the three read-only "Purpose of visit / Duration of stay / Number of entries requested" spans on the Purpose & Duration step, which are server-computed displays driven by the Part 1 selections, not applicant-editable fields; and the payment step's own bank-transfer/merchant fields (`paymentPurpose`, `paymentRecipient`, `paymentAccount`, `paymentConsulate`, `paymentPayerType`, `paymentFullName`, `paymentEmail`, `paymentAmount`, `paymentFee`), excluded as payment mechanics rather than government-form data, consistent with this registry's own established convention. No application was actually submitted for payment and no fee was paid in producing this schema. Filing this application is a traveller action performed directly with the Immigration Agency of Mongolia through evisa.mn; this schema does not file the application itself, and the live source is always authoritative. GovSchema is independent and is not affiliated with, endorsed by, or operated by Mongolia or its Immigration Agency.

Registry entry

mn/mfa/evisa-application

Jurisdiction
Mongolia · national
Version
1.0.0
Verification
draft
Authority
Immigration Agency of Mongolia

Authoritative source The live Electronic Visa Application System's own multi-step wizard at evisa.mn/en/apply, parts 1-4 (Document type & Nationality; Personal information; Purpose & Duration; Data confirmation), rendered server-side and inspected directly via a real browser session after confirming a one-time emailed continuation link.

Machine access

Schema document
registry/mn/mfa/evisa-application/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/mn/mfa/evisa-application/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

49 fields across 4 steps, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Document type & Nationality

  • nationality string required

    The applicant's nationality, selected from the live wizard's own 136-entry `#applicantCountryId` dropdown (a subset of all countries -- the applicant-facing list of nationalities this e-visa channel actually serves, not a full ISO country list). Modelled as a free-text string carrying the site's own opaque numeric option value (e.g. `1002` for Azerbaijan), matching this registry's own precedent for large source-controlled option lists (see `am/mfa/evisa-application`'s `birthCountry`) rather than reproducing all 136 values as an enum.

  • passportType string required

    The applicant's passport type. Populated dynamically per selected `nationality` via a live POST to `/en/callPasstypeData` (confirmed via network trace); only one value, `Ordinary` (wire value `16218326865201`), was returned for the tested nationality (Egypt) this session -- other nationalities may unlock additional values (e.g. Diplomatic/Official/Service), not exhaustively tested. Modelled as a free-text string carrying the site's own opaque numeric option value rather than a hard enum, since the full cross-nationality option set was not confirmed.

  • applicationPurpose string required

    The applicant's broad purpose-of-application category. Also populated dynamically per selected `nationality`/`passportType` via a live POST to `/en/checkPassportType`; two values, `TOURISM` (wire value `20`) and `SPORT OR CULTURAL EVENTS` (wire value `21`), were returned for the tested nationality this session -- other nationalities may unlock additional categories, not exhaustively tested. Modelled as a free-text string carrying the site's own opaque numeric option value for the same reason as `passportType`.

  • email string required

    The applicant's email address. A one-time confirmation link is emailed to this address; following it is required to reach Parts 2-4 (a genuine double-opt-in email-confirmation gate, confirmed live this session -- see VERIFICATION.md).

    pattern

Personal Information

  • firstName string required

    The applicant's first name. The passport-photo-page upload (see `documents[]`, `passportPhotoPage`) auto-fills this field via the site's own OCR pipeline; the field remains a plain, editable text input either way.

    classification: pii
  • lastName string required

    The applicant's last name. Auto-fillable from the passport-photo-page OCR upload, same as `firstName`.

    classification: pii
  • identificationNumber string optional

    An optional national/personal identification number for the applicant. The live field carries no asterisk and no `required`-class marker.

  • gender enum required

    The applicant's gender, a three-option radio group with real, confirmed wire values.

    enum: 1 | 2 | 5classification: pii
  • passportNumber string required

    The applicant's passport/travel document number. Auto-fillable from the passport-photo-page OCR upload.

    classification: sensitive-pii
  • dateOfBirth date required

    The applicant's date of birth, entered in the site's own `yyyy/mm/dd` format (confirmed via the live `pickadate` widget's own `format: "yyyy/mm/dd"` configuration). Auto-fillable from the passport-photo-page OCR upload; the site's own client-side logic computes the applicant's age from this value to decide whether to show the (unmodelled, disclosed) Guardian-information sub-flow for applicants under 18.

    patternclassification: pii
  • passportNationality string required

    The applicant's nationality as it appears on their passport -- a distinct field from Part 1's own `nationality` selector, pre-filled with the Part 1 value by the site's own JavaScript but independently editable (a live, searchable country dropdown, not a fixed subset). Auto-fillable from the passport-photo-page OCR upload.

    classification: pii
  • countryOfBirth string required

    The applicant's country of birth, selected from the live wizard's own full 255-entry `#countryOfBirth` dropdown (confirmed directly from the rendered option list -- e.g. Afghanistan, Algeria, Australia, Azerbaijan, ... through the full set). Modelled as a free-text string carrying the site's own option value rather than reproducing all 255 entries as an enum, matching this registry's own precedent for large country lists.

    classification: pii
  • passportIssuingCountry string required

    The country that issued the applicant's passport, pre-filled from the applicant's nationality by the site's own JavaScript but independently editable.

    classification: pii
  • placeOfBirth string required

    The applicant's place/city of birth, pre-filled from the applicant's nationality by the site's own JavaScript but independently editable.

    classification: pii
  • maritalStatus enum optional

    The applicant's marital status. The live field carries no asterisk and no `required`-class marker on its own `

    enum: 201 | 203 | 16179601837661 | 16218326755461
  • passportIssuedDate date required

    The date the applicant's passport was issued, `yyyy/mm/dd` format.

    patternclassification: pii
  • passportExpiryDate date required

    The date the applicant's passport expires, `yyyy/mm/dd` format. The live page displays an advisory tooltip ("Your passport must be valid for at least 6 months") next to this field; this session did not confirm whether that minimum is also enforced server-side, so it is disclosed here rather than asserted as a hard `validation` rule. See `crossFieldValidation` for the passport issue/expiry ordering rule that is directly confirmed by the fields' own semantics.

    patternclassification: pii
  • currentOccupation string optional

    The applicant's current occupation. The live field carries no asterisk and no `required`-class marker.

  • homeAddress string required

    The applicant's home-country residence address, free text.

    classification: pii
  • homeContactPhone string required

    The applicant's home-country contact telephone number.

    classification: pii
  • emergencyContactName string required

    The full name of the applicant's emergency contact person.

    classification: pii
  • emergencyContactPhone string required

    The phone number of the applicant's emergency contact person.

    classification: pii
  • mongoliaProvince enum required

    The province (or Ulaanbaatar city) where the applicant will stay in Mongolia -- the top level of a real, live-confirmed three-level cascading address selector (Province -> District/Soum -> Subdistrict/Bag). All 21 real Mongolian first-level administrative divisions, confirmed directly from the live dropdown's own option list (numeric `value` attributes are Mongolia's own official province codes, e.g. `11` = Ulaanbaatar, `21` = Dornod).

    enum: 22 values
  • mongoliaDistrict string required

    The district (Ulaanbaatar) or soum (rural province) where the applicant will stay, populated live via AJAX once `mongoliaProvince` is selected (confirmed this session: selecting Ulaanbaatar `11` populates 9 real districts -- Baganuur, Bagakhangai, Bayangol, Bayanzurkh, Nalaikh, Songinokhairkhan, Sukhbaatar, Khan-Uul, Chingeltei). Modelled as a free-text string carrying the site's own dependent-dropdown option value rather than an enum, since the full cross-province option set (21 provinces x their own districts) was not exhaustively enumerated this session.

  • mongoliaSubdistrict string required

    The subdistrict (khoroo, in Ulaanbaatar) or bag (rural) where the applicant will stay, populated live via AJAX once `mongoliaDistrict` is selected (confirmed this session: selecting Bayangol district populates real khoroo entries "1-r khoroo" through "5-r khoroo"). Modelled as a free-text string for the same reason as `mongoliaDistrict`.

  • mongoliaFullAddress string required

    The applicant's full street-level address in Mongolia (hotel, host, or tour accommodation), free text, under the live page's own "Adress in Mongolia" section heading.

  • mongoliaContactPhone string required

    A phone number reachable while the applicant is in Mongolia, under the live page's own "Adress in Mongolia" section heading.

  • hasCriminalRecord enum required

    The applicant's declaration of any prior criminal offence/conviction, a two-option Yes/No radio group with real, confirmed wire values.

    enum: 0 | 1classification: sensitive-pii
  • wasVisaDenied enum required

    The applicant's declaration of any prior Mongolian visa denial, a two-option Yes/No radio group with real, confirmed wire values.

    enum: 0 | 1
  • appliedWithDifferentName enum required

    The applicant's declaration of any prior Mongolian visa application under a different name, a two-option Yes/No radio group with real, confirmed wire values. When "Yes", the live page shows an additional warning to keep this answer consistent with the "Address in Mongolia" section, but does not reveal any further fields this session could confirm beyond that warning text.

    enum: 0 | 1
  • addressConfirmationDocumentType enum required

    Which category of accommodation-confirmation document the applicant holds for their stay in Mongolia (the live dropdown's option text is itself the description of each category, not a short label). Three real, confirmed wire values.

    enum: 16926055267613 | 16926055267614 | 16926055267615

Purpose & Duration

  • declaredFullName string required

    The applicant's full name, re-declared on the Part 3 "VISA APPLICATION FORM FOR FOREIGN NATIONAL" supplementary declaration (a separate field from Part 2's `firstName`/`lastName`, not a client-side mirror of them).

    classification: pii
  • declaredCitizenship string required

    The applicant's citizenship, re-declared on the Part 3 supplementary declaration.

    classification: pii
  • previousCitizenship string required

    Any previous citizenship different from the applicant's current one. The live field carries an asterisk (required) unconditionally -- this session found no separate toggle gating it on a "was your citizenship ever different" question, so applicants without a previous citizenship must enter a placeholder (e.g. "N/A") to satisfy it, per the source's own unconditional asterisk.

    classification: pii
  • declaredPassportNumber string required

    The applicant's passport number, re-declared on the Part 3 supplementary declaration.

    classification: sensitive-pii
  • purposeOfVisitDetail string required

    Free-text elaboration of the applicant's purpose of visit (distinct from Part 1's own coarse `applicationPurpose` category).

  • intendedLengthOfStay string required

    Free-text statement of the applicant's intended length of stay.

  • needsVisaExtension enum required

    Whether the applicant anticipates needing a visa extension, a two-option Yes/No field with real, confirmed wire values.

    enum: 0 | 1
  • lostPassportHistory string required

    Free-text declaration of any prior lost passport, including when and where.

  • priorInvitationDetails string required

    Free-text declaration of any prior Mongolia visit's inviting organization or individual.

  • transitCountries string required

    Free-text list of countries the applicant will transit through before arriving in Mongolia.

  • socialNetworkUsage string required

    Free-text declaration of the applicant's social-network usage and username(s), if any.

    classification: pii
  • countriesVisitedLast10Years string required

    Free-text list of countries the applicant has visited in the last 10 years.

  • specializedSkillsOrTraining string required

    Free-text declaration of any specialized skills or training the applicant holds in the listed categories.

    classification: sensitive-pii
  • mongolianRelatives string required

    Free-text declaration of any relatives who are Mongolian citizens or married to one, including full name, address, and phone.

    classification: pii
  • travelExpensesPayer string required

    Free-text declaration of who (individual or organization) is bearing the applicant's travel expenses.

  • expectedArrivalDate date required

    The applicant's expected date of arrival in Mongolia, `yyyy/mm/dd` format. The live page displays an advisory note that this date cannot be the same as the application submission date; this session did not confirm that as a hard server rule, so it is disclosed here rather than asserted as a `validation` rule.

    pattern
  • expectedDepartureDate date required

    The applicant's expected date of departure from Mongolia, `yyyy/mm/dd` format.

    pattern

Data Confirmation

  • agreesToTermsAndConditions boolean required

    The applicant's attestation that they agree to the e-Visa system's terms and conditions, the final gate before payment.

Verification record

Candidate selection

GOV-3375 ("GovSchema Standard Research") scouted Mongolia's Electronic Visa Application System (evisa.mn, run by the Immigration Agency of Mongolia under immigration.gov.mn, live since 2021) as a new-jurisdiction candidate. Mongolia had no prior schema of any kind in this registry; this opens it as a new jurisdiction with one vertical (Visa). Two other candidates were screened first this cycle and set aside as weaker: Uzbekistan's five remaining non-Visa verticals (DMV/Passport/Business Formation/Taxes/National ID), all funnelled through the my.gov.uz single-window portal, whose service pages turned out to be Nuxt-rendered marketing/description pages requiring an ESI/e-imzo digital-signature login to see the actual application form, not a live unauthenticated wizard; and Ethiopia's Fayda national ID (id.gov.et) and e-Trade business registration (etrade.gov.et), the former confirmed too thin (5 demographic fields plus device-captured biometrics, no online form) and the latter unreachable this session.

Reaching the live source

Fetched https://www.evisa.mn/en/apply directly with a plain curl and a standard desktop Chrome User-Agent string (HTTP 200) and then drove it live with Playwright + system Chromium (/app/node_modules/.pnpm/playwright@1.58.2, executablePath /paperclip/.cache/ms-playwright/chromium-1228/chrome-linux64/chrome, with LD_LIBRARY_PATH=/paperclip/chrome-sysroot/usr/lib/x86_64-linux-gnu:/paperclip/chrome-sysroot/usr/lib). No login, CAPTCHA, or WAF gate blocks reaching or loading the wizard's Part 1.

The gate between Part 1 and Parts 2-4: a genuine email-confirmation link, not a CAPTCHA

Part 1 ("Document type & Nationality") collects nationality, passportType, applicationPurpose, and email, then submits. Submitting does not advance the in-browser wizard to Part 2 directly — it shows a "PLEASE, CHECK YOUR EMAIL" screen and redirects to https://www.evisa.mn/en/cmail/<code>. This is architecturally the same shape as this registry's own am/mfa/evisa-application (a CAPTCHA-plus-emailed-token gate) but is, precisely, a plain double-opt-in email-confirmation gate with no CAPTCHA at all — confirmed by the fact that no CAPTCHA/reCAPTCHA widget or challenge of any kind appears anywhere in Part 1's markup or network traffic.

This session used a real, disposable public inbox (mailinator.com, no signup required, a public/no-authentication temporary mailbox — not a real applicant's identity, and no real government-issued credential of any kind was used or impersonated) to legitimately receive and follow that confirmation link, the same category of action as confirming a newsletter subscription:

  • Submitted Part 1 with nationality Egypt, passport type Ordinary, applying-for Tourism, and email govschema-research-2026@mailinator.com.
  • Retrieved the resulting email directly via Mailinator's own public JSON API (GET https://www.mailinator.com/api/v2/domains/public/messages/<id>). Sender: E-VISA <e-visa@immigration.gov.mn>. The message carries a valid DKIM signature (d=immigration.gov.mn) and its Received chain traces through security.mail.gov.mn (203.26.189.111) and mtaout1.gov.mn — confirming the email genuinely originated from Mongolia's own government mail infrastructure, not a spoof.
  • The email's own body contains exactly one link: https://www.evisa.mn/en/apply/<token>. Following it in the same Playwright session reached the full Parts 2-4 markup — 103 form elements in a single page load (confirmed via document.querySelectorAll('input, select, textarea')), all rendered via the jquery.steps plugin (CSS visibility toggling between parts, not separate page requests per part).
  • No application was submitted for payment and no fee was paid.

Structure of the source: a real multi-step server-rendered wizard

assets/page/js/theme/apply.v1743406415.js (the wizard's own client-side logic, fetched directly and inspected) is not obfuscated. Its case statements for iscrime/isdenied/isdefirentName/additionalInformation18/ gender/e_gender and its OCR-response switch statement (LastName, FirstName/Name, PassportNumber, Nationality, DateOfBirth → corresponding named inputs) were read directly, not inferred, and inform several fields' description/sourceRef text below (in particular the passportPhotoPage document's declared ocr.populatesFields list and the disclosed Guardian-sub-flow age-threshold logic).

Every field's name, required-asterisk marking (<span class="danger">*</span> immediately after the field's own <label>), and dropdown option list documented in schema.json was read directly from the live-rendered HTML captured after following the confirmation link — via document.querySelectorAll/regex extraction on the saved page source, not eyeballed or guessed. Two live cascading dependent-dropdown AJAX endpoints were also confirmed directly via network trace:

  • POST /en/callPasstypeData — populates passportType's option list from the selected nationality.
  • POST /en/checkPassportType — populates applicationPurpose's option list from the selected nationality/passportType.
  • The mongoliaProvince → mongoliaDistrict → mongoliaSubdistrict cascade (Province → District/Soum → Subdistrict/Bag) was independently exercised live: selecting Ulaanbaatar (11) populated 9 real districts (Baganuur, Bagakhangai, Bayangol, Bayanzurkh, Nalaikh, Songinokhairkhan, Sukhbaatar, Khan-Uul, Chingeltei); selecting Bayangol populated 5 real khoroo entries ("1-r khoroo" through "5-r khoroo").

Field-by-field notes

  • nationality/passportType/applicationPurpose: all three carry the site's own opaque numeric/timestamp-style option values (e.g. 1002 for Azerbaijan, not a human-readable slug), consistent with this being a database-driven admin-managed lookup rather than a hardcoded enum in client code (contrast this registry's own Armenia/Georgia MFA schemas, whose AngularJS/ASP.NET sources embed clean semantic enum values directly in their own JavaScript). Modelled as free-text string rather than a fully-reproduced enum, matching this registry's own established precedent for large or dynamically-populated option lists (see am/mfa/evisa-application's birthCountry). passportType and applicationPurpose were each observed with only 1-2 real options for the one nationality (Egypt) tested this session; other nationalities may unlock additional values not confirmed here — disclosed in each field's own description, not silently assumed exhaustive.
  • gender/hasCriminalRecord/wasVisaDenied/appliedWithDifferentName/ needsVisaExtension/maritalStatus/addressConfirmationDocumentType: all seven are small, source-confirmed bounded lists (2-4 real options each), modelled as enum with the exact live wire value attributes (e.g. gender 1/2/5 — not sequential, but confirmed directly from the raw <input value="..."> markup, not assumed).
  • countryOfBirth: the live #countryOfBirth dropdown carries a full, genuine 255-entry option list (Afghanistan through Zimbabwe, alphabetic), confirmed directly, not a placeholder. Modelled as string per this registry's own large-country-list precedent.
  • passportNationality/passportIssuingCountry/placeOfBirth: these three <select> elements are pre-populated with the applicant's Part-1 nationality by the site's own JavaScript but remain independently editable (searchable select2 widgets) — not fixed/locked fields.
  • Two crossFieldValidation rules were added based on the fields' own semantics, not the source's own explicit runtime enforcement (which this session did not fully verify server-side): passportExpiryDate after passportIssuedDate, and expectedDepartureDate after expectedArrivalDate. Both date fields use the site's own yyyy/mm/dd format (confirmed via each pickadate({format:"yyyy/mm/dd"}) initialization call), which sorts correctly under a plain string greaterThan comparison.

Disclosed scope boundaries (not silently dropped)

  1. Guardian-information sub-flow (b_firstName, b_lastName, b_addressDescription, e_applicantcountryid, e_dateOfBirth, e_gender, e_optionalData, e_expiryDate, e_presentTelephoneNumber — all carrying live asterisks when shown). Confirmed directly from apply.v1743406415.js: when the passport-photo OCR reads a DateOfBirth indicating the applicant is under 18 at submission time, the client shows a warning dialog (vis_guardians_18) and this sub-flow. This is a genuinely computed condition (current date minus a parsed date-of-birth, evaluated by the site's own JavaScript), not a static field-to-field comparison — outside what this registry's Condition grammar (equals/notEquals/in/greaterThan family, referencing only other field values) can express. This session also had no fabricated minor's passport image with which to trigger the OCR path live. Left unmodelled and disclosed here rather than force-fit or guessed.
  2. Three read-only summary spans ("Purpose of visit", "Duration of stay", "Number of entries requested") on the Purpose & Duration step, confirmed to be server-computed displays bound to the Part 1 visa-type selection (data-path attributes, not name-bearing form inputs) — not applicant-editable fields.
  3. Payment-step fields (paymentPurpose, paymentRecipient, paymentAccount, paymentConsulate, paymentPayerType, paymentFullName, paymentEmail, paymentAmount, paymentFee) and the payment-method checkboxes (JCB/Amex/UnionPay/Mastercard/Visa) — excluded as payment mechanics rather than government-form data, consistent with this registry's own established convention (see e.g. uz/mfa/evisa-application's Click.uz scope boundary).
  4. No application was submitted for payment and no fee was paid producing this schema.

Conformance

2 valid fixtures (0 errors each — a tourism applicant with every optional field present, and a sport/cultural-event applicant with the three genuinely optional fields, identificationNumber/currentOccupation/ maritalStatus, omitted entirely) plus 7 mutation-control fixtures (each raising exactly 1 error: a plain missing-required-field case, an invalid-enum case, two invalid-pattern cases, both crossFieldValidation rules' violations, and a required-boolean-attestation-not-true case) are committed under conformance/mn/mfa/evisa-application/1.0.0/. All 9 were independently re-checked this session against a from-scratch mock validator implementing this schema's required/enum/pattern/ crossFieldValidation rules, each producing the exact expected error count. Both tools/validate.mjs and tools/validate-ajv.mjs pass with this document included.

View the raw record (VERIFICATION.md)

Version history

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

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Immigration Agency of Mongolia or any government. The authoritative source is always the live government form and its official instructions.