Ethiopia e-Visa Application

The category of visa being applied for, read directly from the live visa-category ``'s 13 real options. This schema models the Tourist Visa branch; other branches (e.g. Medical Treatment Visa) reveal additional/different downstream fields not modelled here — see `companyReferenceNumber` and VERIFICATION.md.

enum: 13 values

visaValidity enum required

The visa's validity/entry option. This field's option set cascades from `visaType` — live-confirmed to offer exactly one option ("Single Entry 30 Days") for Tourist Visa, but four options for Medical Treatment Visa ("Single Entry 30 Days", "Multiple Entry 6 Months", "Multiple Entry 1 Year", "Multiple Entry 90 Days"). Only the Tourist Visa branch's single confirmed value is modelled here, consistent with this schema's Tourist Visa scope; other `visaType` selections may reveal different/additional validity options not enumerated below — a disclosed judgment call, see VERIFICATION.md.

enum: SINGLE_ENTRY_30_DAYS

companyReferenceNumber string optional

A reference number tying the application to a sponsoring company, required only when Medical Treatment Visa is selected — confirmed live via the field's own real-time "Company Reference Number is required!" validation message, which appears only on that branch. Not present at all for Tourist Visa.

length: 0–100

termsAccepted boolean required

The applicant's acceptance of the site's terms and conditions. The live "Next" button is genuinely blocked ("Please agree terms and conditions") until this box is checked.

Arrival Information / Address in Ethiopia

• arrivalDate date required

  The traveller's planned date of arrival in Ethiopia, selected live via an Ant Design calendar widget.

  pattern
• departureCountry string required

  The country the traveller is departing from, selected from the live portal's own complete country picker (confirmed to include entries alphabetically from Afghanistan; not reproduced in full here, consistent with this registry's convention for large country pickers — see VERIFICATION.md).

  length: 0–100
• departureCity string required

  The city the traveller is departing from.

  length: 0–100
• airline string optional

  The airline the traveller is arriving on. Confirmed live to carry no asterisk and no required-field validation error, unlike every neighbouring field on this step.

  length: 0–100
• flightNumber string optional

  The traveller's flight number. Confirmed live to carry no asterisk and no required-field validation error, unlike every neighbouring field on this step.

  length: 0–20
• accommodationType enum required

  The type of accommodation the traveller will stay in while in Ethiopia, read directly from the live `

`'s 4 real options.

The name of the hotel/guest house/resort where the traveller will stay.

The city of the traveller's accommodation in Ethiopia.

The street address of the traveller's accommodation in Ethiopia.

The telephone number of the traveller's accommodation in Ethiopia. The live input is a phone widget pre-filled with a non-removable "+251" country-code prefix that the applicant appends digits to.

The traveller's given name(s).

The traveller's surname.

The traveller's country of citizenship, selected from the live portal's own complete country picker (confirmed live to offer 260 entries, alphabetically from Afghanistan; not reproduced in full here, consistent with this registry's convention for large country pickers).

The traveller's gender, a two-option radio group.

The traveller's country of birth, selected from the same complete country picker as `citizenship`.

The traveller's date of birth, selected live via an Ant Design calendar widget.

The traveller's specific place (city/town) of birth.

The traveller's email address.

Repeat entry of the traveller's email address; must match `emailAddress` exactly.

The traveller's own contact phone number, entered via the same kind of country-code-prefixed phone widget as `accommodationTelephone`.

The traveller's occupation, a free-text field (confirmed live to be a plain text ``, not a dropdown, unlike this registry's `ke/immigration/eta-visa-application` occupation field).

The traveller's home street address.

The city of the traveller's home address.

The country of the traveller's home address, selected from the same complete country picker as `citizenship`.

The type of travel document being presented, read directly from the live ``'s 3 real options. This step's fields were confirmed present, labelled, and marked required via direct DOM inspection (the site pre-mounts every step's markup on initial page load) but were not interactively filled and validated live this session — an accepted scope boundary, see VERIFICATION.md.

enum: ORDINARY_PASSPORT | LAISSEZ_PASSER | TRAVEL_DOCUMENT

passportNumber string required

The passport/travel document number.

length: 0–20classification: sensitive-pii

passportIssueDate date required

The date the passport/travel document was issued.

pattern

passportExpiryDate date required

The date the passport/travel document expires.

pattern

issuingCountry string required

The country that issued the passport/travel document, selected from the same complete country picker as `citizenship`.

length: 0–100

passportIssuingAuthority string required

The specific authority that issued the passport/travel document.

length: 0–150

Verification record

Candidate selection

GOV-3313 ("GovSchema Standard Research", 2026-07-16). Ethiopia has zero schemas in the registry prior to this cycle. Rather than re-screen the registry's many already-confirmed dead ends (see prior cycles' own CATALOG.md history), this cycle scouted for genuinely new jurisdictions via the pattern that worked recently for Kenya (ke/immigration/eta-visa-application) and Ecuador (ec/cancilleria/formulario-solicitud-visa): live, unauthenticated tourist e-visa portals, since foreign travellers cannot be assumed to hold the destination country's own national digital ID, so these systems are structurally more likely to be reachable without a login wall.

Five candidates were scouted in parallel this cycle:

• Cambodia (evisa.gov.kh) — reachable (HTTP 200) but serving an identical ~330-byte NSFOCUS/Nexusguard WAF "Site is not available" stub on every path tried, reproduced identically by curl and by a real Chromium browser. TLS-certificate-confirmed (O=Ministry of Foreign Affairs and International Cooperation, CN=www.evisa.gov.kh, valid through Jan 2027) as a genuine, maintained government domain — this is a live outage, not a retired service (independently corroborated by a contemporaneous public TripAdvisor thread reporting the same symptom). Not authored this cycle; worth re-checking in a future cycle rather than treating as a dead end.
• Uzbekistan (e-visa.gov.uz) — a real, live Angular SPA (VisaClient2) backed by a working REST API (step 1's four dropdowns — citizenship, document type, entry type, purpose — all populated with real data). Blocked by a client-side rendering bug: a "Loading…" overlay never clears after step 1, even though the underlying API calls succeed, across UA-spoofing and automation-flag-masking attempts. Step 1's four fields were confirmed but steps 2 onward could not be reached. Not authored this cycle.
• Ethiopia (evisa.gov.et) — this schema.
• Georgia (evisa.gov.ge) — a strong candidate: a classic server-rendered ASP.NET MVC wizard where the entire ~74-field, 5-step form is present in a single page load (client-side JS only shows/hides sections), reachable via a normal desktop-Chrome User-Agent string with no login/account/payment gate — the only gate found is a CAPTCHA on final submission, which does not block viewing the full field structure. Left as a disclosed, ready-to-author backlog item for a future cycle rather than authored this same session (see the GOV-3313 research issue's own comment thread for the full scouting report).

Ethiopia's Immigration And Citizenship Service (ICS) e-Visa portal was selected for authoring this cycle because it was the candidate most thoroughly live-walked and live-validated: a real multi-step React application with rich field variety (text/date/dropdown/radio/checkbox), genuine cascading conditional logic, and zero blocking gates encountered through three of its six steps.

Reaching and walking the live wizard

Reached directly at https://www.evisa.gov.et/visa via the homepage's "Apply Visa" navigation link — no signup or login gate at any point. Walked live with Playwright + Chromium (executablePath pointed at the locally cached Chromium build, LD_LIBRARY_PATH set for the sysroot's libraries, waitUntil: 'domcontentloaded' plus explicit settle delays — this is a React SPA that a plain WebFetch/curl cannot render at all; an initial WebFetch attempt returned only the page's <title>).

A structural discovery shaped this session's methodology: the site pre-mounts every one of its six steps' full form markup (<label>/<input>/<select>) into the DOM on the very first page load. Only visibility and interactivity are gated per-step by React state — later steps' elements exist and are queryable via document.querySelectorAll immediately, they are simply not :visible (and so not Playwright-actionable) until the wizard actually navigates there. This was used to independently corroborate the Passport Information step's field labels, name attributes, and required markers via direct DOM inspection, even for the sub-step this session's live navigation did not reach.

Live-filled and live-validated, with real Playwright browser interactions (not programmatic value-setting), through three of six steps:

1. Visa Category: selected "Tourist Visa" from a PrimeReact .p-dropdown (13 real options read from the live DOM), selected its sole "Single Entry 30 Days" validity option, checked the terms checkbox, clicked "Next" — genuinely blocked ("Please agree terms and conditions") until checked.
2. Arrival Information / Address in Ethiopia: selected an arrival date via a real Ant Design (ant-picker) calendar click (not a programmatic value — the field's own "Arrival Date is required!" message was live-observed clearing only on a real cell click), filled departure country/city, airline, flight number, then the accommodation sub-section (type, name, city, street address), and finally a country-code-prefixed phone widget (pre-filled +251, appended real digits via keyboard.type, since .fill() does not correctly handle this widget's cursor-position-dependent input). "Next" was genuinely blocked once ("Accommodation Telephone is required") until the phone field held a real value beyond the bare prefix.
3. Personal Information: filled given name/surname, selected citizenship and country of birth from the live country picker (260 real entries, confirmed via forced DOM inspection — see below), selected "Male" from a two-option radio group, opened and selected a date via the Date-of-Birth ant-picker calendar (screenshotted live, showing July 2026 with the current day highlighted), filled place of birth, email + confirmation, phone, occupation, and street address/city/country. This step was reached and its full field set visually confirmed via screenshot; the final "Next" click into Passport Information hit an unrelated automation-tooling flake in this session (a stale-element/timing issue, not a site-side validation failure) and was not re-attempted given the field-level fidelity already obtained by this point.

Enum value lists — exact provenance

Rather than rely on Playwright's default :visible-gated click actions (which fail for a later step's own dropdowns while an earlier step is active), each closed enum's option list was extracted by dispatching a raw MouseEvent('click') directly at the target .p-dropdown element via page.evaluate, bypassing Playwright's visibility actionability check — justified here specifically because the underlying DOM node already provably exists (per the pre-mounting discovery above), so this is reading real, already-rendered option data, not fabricating it:

• visaType (13 options) — read from the live, always-visible Visa Category dropdown directly.
• accommodationType (4 options: Hotel, Guest House, Resort, Other) — force-extracted.
• passportType (3 options: Ordinary Passport, Laissez-passer, Travel Document) — force-extracted from the Passport Information step's pre-mounted (but not-yet-visited) dropdown.
• gender (2 options: male/female) — read directly from the live radio group's own id attributes (#male/#female), confirmed present in the DOM regardless of step visibility.
• citizenship/countryOfBirth/departureCountry/addressCountry/issuingCountry — all five select from the same complete, alphabetically-ordered country picker (force-extracted and counted at 260 real entries via the citizenship dropdown, starting Afghanistan, Albania, Algeria...). Consistent with this registry's established convention for large country pickers (e.g. Kenya's residenceCountry), these are modelled as free-text string, not a closed enum.
• visaValidity — confirmed live to cascade on visaType: exactly one option ("Single Entry 30 Days") for Tourist Visa, but four options ("Single Entry 30 Days", "Multiple Entry 6 Months", "Multiple Entry 1 Year", "Multiple Entry 90 Days") when Medical Treatment Visa is selected instead — confirmed by actually re-selecting Medical Treatment Visa and re-opening the validity dropdown. Only the Tourist Visa branch's single confirmed value is modelled (see Disclosed judgment calls below).

A genuinely conditional field, defeated live rather than assumed

Selecting "Medical Treatment Visa" instead of "Tourist Visa" reveals a required companyReferenceNumber text input (input[name="companyReferenceNumber"]) that is not present at all for Tourist Visa — confirmed by re-selecting Medical Treatment Visa and observing both the field's appearance and its own live "Company Reference Number is required!" validation message. This is modelled as requiredWhen: { field: "visaType", equals: "MEDICAL_TREATMENT_VISA" }, per GSP-0013's Condition grammar — the same convention this registry uses elsewhere for genuinely branch-dependent fields.

Disclosed scope boundary

Passport Information's six fields (passportType, passportNumber, passportIssueDate, passportExpiryDate, issuingCountry, passportIssuingAuthority) were confirmed present, correctly labelled, and marked required via direct DOM inspection of the page's pre-mounted markup — but were not interactively filled and live-validated this session, unlike every preceding step. Their sourceRefs say so explicitly ("DOM-confirmed, not interactively validated").

Review and Attachments were not reached at all. Unlike every preceding step, zero input[type="file"] elements exist anywhere in the page's DOM at initial load — the Attachments step's upload component appears to mount only once that tab actually becomes active, breaking the pre-mounting pattern this session otherwise relied on. Rather than guess at a plausible document list (e.g. "passport bio-data page" + "photo", by analogy with this registry's other visa schemas), this schema omits documents[] entirely and discloses the gap here — an accepted scope boundary, consistent with this registry's precedent for tz/immigration/passport-application (stopped at Attachments) and rw/irembo/nida-diaspora-application (stopped at step 1 of 3). No visa fee was paid and no application was actually submitted in producing this schema.

Disclosed judgment calls

• visaValidity is modelled as a single-value closed enum (SINGLE_ENTRY_30_DAYS), scoped to the Tourist Visa branch only. Since this field's real option set is confirmed to cascade on visaType (1 option for Tourist, 4 for Medical Treatment), and only the Tourist Visa branch was live-walked end to end, modelling every other visaType branch's validity options would require re-walking each of the other 12 visa types individually — out of scope for this cycle, consistent with how this registry's Kenya schema scoped applicationCategory down to only its tested branch.
• occupation is modelled as free-text string, not enum. Confirmed live to be a plain <input type="text">, not a <select> — a genuine structural difference from this registry's ke/immigration/eta-visa-application, whose occupation field is a 57-option closed enum. Not every visa portal that asks for occupation constrains it to a closed list.
• companyReferenceNumber has no maxLength confirmed live (the field was observed to appear and become required, but was not interactively filled with a boundary-testing value); maxLength: 100 is a conservative placeholder consistent with this schema's other free-text reference fields, not a live-confirmed constraint.
• accommodationTelephone/phoneNumber have no static name attribute (a phone-input widget controls them via React state, not a bare HTML form name); identified instead by their unique on-page label text, and their maxLength values are read from the live maxlength="17" HTML attribute (accommodationTelephone) or a conservative placeholder consistent with this registry's other phone fields (phoneNumber).

Validation

• node tools/validate.mjs / node tools/validate-ajv.mjs — 505/505 (505/505 with ajv, meta-schema v0.3), up from the pre-existing 504/504 baseline.
• node tools/verify-sources.mjs --base origin/main — 1 directory, 3 URLs checked, 0 warnings, all clear.
• Conformance fixtures under conformance/et/ics/e-visa-application/1.0.0/: valid fixtures plus mutation-control fixtures each raising exactly one error, including the companyReferenceNumber requiredWhen cascade and the emailAddressConfirmation cross-field mismatch rule.

GovSchema is independent and is not affiliated with, endorsed by, or operated by the Federal Democratic Republic of Ethiopia or its Immigration And Citizenship Service. This schema does not file the application itself; the live source (evisa.gov.et) is always authoritative.

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

More from ICS

• et/ics/passport-application

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 Immigration And Citizenship Service or any government. The authoritative source is always the live government form and its official instructions.