How we verify entry requirements
What we check
Requirements pages and filing pages are built from one data file, not generated at request time. Each country has a short answer, a process type (visa-free / ETA / e-visa / arrival form / embassy), an official source URL when we have one, and a lastVerified date.
We are not a government body. We compare our wording to the destination’s official immigration portal (or equivalent government source) and say so when a rule is uncertain.
What “Last checked” means
lastVerified is a date set by hand after a person compared the rules to the official source. It does not update at build time, from the calendar month, or from the deploy date.
JSON-LD dateModified on those pages equals lastVerified. Page titles show only the year from that date.
TODO: a fixed recheck schedule (for example quarterly, or after an official fee-change notice). There is currently no cron that re-fetches government sites — only a manual reminder in the data file.
How “From our applications” stats are calculated
Once a night the system re-reads production orders (no names, passports, or emails). We count only orders that reached submitted, delivered, or rejected — not drafts.
- Application count: shown only if there are at least 10 processed applications for that country. Otherwise the block is hidden.
- Median and 90th-percentile days: from the submitted stamp in the admin action log to the delivered stamp. Orders missing either stamp are excluded from the timing calculation.
- Approval rate: delivered divided by (delivered + rejected), shown only from 20 applications up.
- Rejection reasons: there is currently no structured rejection-reason field on orders. The block does not invent reasons.
TODO: add a reason code or tagged order note if you want the top three rejection/return reasons on the page.