There is a new list in the partner console: every destination we hold requirement data for. Tick the ones you sell. From then on, when a rule changes for one of them, an email arrives about that one change. In a quiet week nothing arrives at all, because there is nothing to send.
Who ticks what is up to you. Most partners start with their top twenty destinations by volume and add the rest once they see how little noise it produces.
What an alert says
Every alert is built the same way, so the shape becomes familiar after two of them. Four things, in this order:
We write them to survive a forward. Someone on your ops team should be able to drop one into a channel and have the people there act on it without opening anything. The source link is there so you can check us when a change looks surprising.
Why one email per change
The convention in this corner of travel is a weekly digest, and we have read plenty of them. A digest of ten changes buries the one line that matters to you under nine that do not, and it lands on a schedule that has nothing to do with when the border moved. By the time it arrives, the interesting item is four days old and sitting between two that do not touch your book.
One change per email makes the email a unit your team can handle. It can be routed to whoever owns that market and forwarded on its own, without anyone having to cut a paragraph out of something longer. It can be filtered by destination into whatever inbox rules you already run.
Often the subject line does the work on its own: the destination, and what moved. That is the test we hold the format to.
Where they come from
Nothing new sits behind this. Every week the coverage team works through government sources for the destinations we cover and records what has changed, which is the same work that keeps the requirements data current. When a change is confirmed, it publishes to the API, to the changelog and to the alert email the same day, off the same record. There is no separate alerts pipeline to fall behind.
It also means an alert is a human-reviewed change, not a page diff. Government sites reword and republish pages constantly without altering a single rule; a diff-driven alert fires on all of that. Ours fires when someone has read the change and decided it affects who can travel and how.
Everything that triggers an alert email also publishes as an event, so a system can consume it directly. Subscribe to the rule-change event and the payload carries the destination, the affected nationalities and the effective date, with the same source reference the email shows. The webhook reference has the full shape. The email is for the people; the webhook is for the queue. Teams often take both, and turn the email off for whichever destinations the code already handles.
Two limits worth knowing before you switch it on. Alerts cover rule changes only: processing times drift constantly and would drown the signal, so those stay in the API response and in the console, where you can look them up when a traveler asks. And an alert follows the destination, so a change that reaches your travelers through a transit stop only finds you if the transit country is ticked. If you sell connections through the Gulf, or through China, tick those as well as the places people are actually going.