Hardly any parte de viajeros (the traveller report Spanish hosts must file) gets rejected because of the host. It gets rejected because, three days earlier, a guest misspelled their municipality, picked the postal code of the town next door, or abandoned a form halfway through in an airport queue. The mistake is made on the traveller’s phone and shows up weeks later, when there is nobody left to ask.
So we rebuilt Regi’s online check-in from the ground up: not to make it prettier, but to make sure the data arrives correct the first time. Every field a guest hesitates over is a report that comes back wrong, so the work went into removing hesitation, validating whatever can be validated against official data, and warning people at the moment they make a mistake rather than long afterwards.
This post is about what changed in the flow and why it produces a correct filing. The legal framework is covered in our guide to traveller registration and RD 933/2021 (the Royal Decree that governs it), and the arrival experience in general in the check-in app post.
The error is not in the submission, it is in the form
A parte de viajeros is, at heart, a handful of fields that have to be exact. Sending it to SES.Hospedajes (the Spanish Ministry of the Interior platform that receives these filings) is the easy part: the system does it on its own. The hard part is getting those fields in correctly from the phone of someone halfway through packing a suitcase. And when a field goes in wrong, the cost is not a red warning on a screen: it is a filing you have to correct, or cancel and redo, sometimes with the stay already under way. The most common rejection messages and how to fix them are in SES.Hospedajes errors.
With that in mind we changed three things: let the guest finish the form even when they get interrupted, stop making them guess anything we can know for them, and warn them at the moment they get something wrong.
Drafts that save themselves and resume where you left them
Check-in is no longer a one-sitting form. It saves step by step, and every draft has its own link, /d/{token}, which the guest can open later or on another device and find just as they left it.
The detail that changes the most in practice is expiry: the draft is tied to the stay, not to the editing session. Before, closing the tab or losing signal meant starting over, which is precisely the moment a rushed guest starts typing anything just to be done. Now they can start on the plane, stop halfway and finish at the property without losing a thing. Fewer abandoned forms means fewer check-ins done at the last second in the doorway, and the doorway is where transcription errors cluster.
Several people filling in at once, without overwriting each other
A booking for four adults is four people typing at the same time the moment you send them a link. That used to be a problem: two guests on the same slot could overwrite each other and end up with mixed-up details.
Now each traveller slot has a soft, expiring edit hold. While somebody is filling in a slot, everyone else can see it is taken; and because the hold expires by itself, nobody ends up locked out of a slot just because someone else’s battery died. It is a safeguard, not a barrier.
The screen also updates live. We used to poll the server every three seconds; now changes arrive on their own, and in a large group seeing who has already finished saves the round of “have you done yours yet?” messages.
Postal code and municipality: where a filing is really won or lost
This is the least glamorous change and the one that saves the most reports. The traveller’s address does not travel to the filing as free text: what travels is a municipality code. If that code is wrong, the report is not “slightly imprecise”, it is a rejected filing. And a foreign guest (or a Spanish one, let us be honest) has no reason to know whether their village is a municipality in its own right or a hamlet attached to another one.
So the check-in now includes exhaustive Spanish postal code and municipality validation, using data derived from the public INE dataset:
- Postal code first. The guest types the five digits, the piece they know by heart, and the municipalities belonging to that code are offered from there. Not the other way round.
- Autofill when there is no ambiguity. If a municipality has a single postal code, it fills itself in. One field fewer to touch is one field fewer to get wrong.
- No impossible combinations. Postal code plus municipality pairings that do not exist cannot be selected, so they never reach the filing.
The result is not cosmetic: the municipality that gets submitted is a real code, not a hand-typed approximation.
Fields you fill in without thinking
The rest of the form got the same treatment: remove friction wherever friction produces errors.
- Multilingual fuzzy search for countries and municipalities: a German guest types “Spanien”, a French one “Espagne”, and one accent more or less leaves nobody stuck.
- The flag of the selected country, so it is obvious at a glance that it is the intended one (Austria and Australia get confused more often than you would think in a long list).
- One-tap sex selection, no dropdown.
- A mobile keyboard matched to each field: numeric for the document number and the postal code, the right one for email. That is the difference between typing a postal code in two seconds or in ten with two typos.
All of this comes with accessibility work and first-load performance work: check-in gets opened by people on bad connections, roaming, and using screen readers.
Warnings before the mistake reaches the filing
Validating individual fields is not enough; some errors only appear when you look at the whole booking. The flow now speaks up in three specific situations:
- Date conflicts, both when the check-in is created and when the dates are edited afterwards. If those dates clash with another registered stay at the same property, you hear about it before going any further, not once the report has been filed.
- Unusually long stays. It does not block anything (long stays are legitimate), but it asks: most of the time it is a mistyped year in the departure date.
- A party made up only of minors. Instead of letting a check-in through with no adult on it, the flow guides the group to add a responsible adult.
We also removed questions that only produced invented answers:
- The payment method is only asked after asking whether the platform already charged. If Airbnb or Booking.com already took the money, asking the guest how they paid is an invitation to pick an option at random.
- No support number is submitted for documents that are not a NIF or NIE. A passport has no support number, so it is neither asked for nor padded with a filler value that would later pollute the filing.
The ending: confirmation seal and a receipt PDF
Check-in finishes with a confirmation screen carrying a seal and a downloadable receipt PDF: the guest knows they are genuinely done, and has something tangible to show when someone else in the group asks whether “that registration thing” is sorted.
Check-in is available in seven languages: Spanish, English, German, French, Dutch, Czech and Polish. A legal form in a language you do not command is an error factory; in the traveller’s own language, it is a two-minute errand.
How that form reaches the guest (short link, QR code and per-channel setup) is covered in the post on the check-in link and QR code, and what happens to the data once submitted (kept for three years, then deleted automatically) is explained in the post on guest data protection.
On the host side: cleaner, more manageable reports
A better form only pays off if the other end keeps up. The reports screen changed too:
- Download the parte de viajeros as a PDF from the reports table, to archive or show without taking screenshots.
- Send and retry a report from the interface, instead of depending on an automatic retry you cannot see.
- Cancelled reports no longer trigger the date-conflict warning: it now fires only on a real conflict.
- Municipality codes are validated as real INE codes on the report side too, so the form’s validation and the submission’s validation say the same thing.
- Compact stay dates in the table, so a long list can be read without going field by field.
The detail on what can be corrected and what redoing a filing involves is in the post on cancelling partes; the general context of the procedure, in the traveller registration guide.
Frequently asked questions
What happens if a guest leaves the check-in half done?
Nothing is lost: the draft saves step by step and has its own /d/{token} link to resume exactly where they left off, even from another device. Expiry is tied to the stay, not to the editing session.
Can several guests fill in their details at the same time? Yes. Each traveller slot has a soft, expiring edit hold, so two people cannot overwrite each other. Changes appear live, with no page reload.
Why do the postal code and municipality matter so much? Because the parte de viajeros carries a municipality code, not a hand-typed town name, and if that code is wrong the filing is rejected. That is why selection is postal-code-first and validated against data derived from the public INE dataset.
Which languages can a foreign guest check in with? Seven: Spanish, English, German, French, Dutch, Czech and Polish.
Can I download the parte de viajeros? Yes, as a PDF from the reports table. You can also send or retry a report’s submission from the interface itself.