Filing guests with the authorities in Spain and Italy, automatically
Guest registration is the one part of running accommodation where "we will do it on Monday" is not an option. Deadlines run from arrival, including weekends, and Italy applies a shorter limit to stays under 24 hours.
Official sources
The obligation, briefly
If you host paying guests in Spain or Italy, traveller data must be communicated through the applicable authority service: SES.Hospedajes in Spain and Alloggiati Web in Italy. The deadline is measured from arrival, not checkout; Italy currently requires communication within 24 hours, or within six hours for stays shorter than 24 hours. Requirements apply to each guest, not only to the booking.
This guide is about what that means for software. It is not legal advice, and the operative requirements change; confirm the current rules with the authority or your own adviser before relying on any implementation.
Why the deadline changes the architecture
A 24-hour deadline sounds generous until you notice what it rules out.
It rules out filing as a side effect of a nightly batch, because a guest arriving at 18:00 on Friday cannot wait for whatever runs on Monday. It rules out filing inline with check-in and hoping, because if the authority's endpoint is down at that moment the record is simply lost and nothing will try again. And it rules out treating a failed submission as an error to display, because the person who would have seen the error has gone home.
What it demands instead is a queue with retries running at least hourly, and a record of what was filed, when, and with what reference. In Boris the registration step is one of the four execution areas marked required, precisely because its failure is silent and its consequence is a fine.
The two systems fail in different ways
They are not variations on one integration. They are genuinely different shapes, and a system that abstracts them too early will get both wrong.
SES.Hospedajes is a SOAP service, and the payload is not plain XML: the actual data travels as a compressed archive embedded inside the SOAP envelope. That single detail defeats most naive implementations, because everything looks like a normal web service call until you discover the body has to be zipped first.
Alloggiati Web takes fixed-width text records — each guest one line of exactly 168 characters, every field at a defined offset, padded rather than delimited. There is no forgiveness in that format. A field one character short shifts everything after it, and the record is rejected as a whole with an error that points at the line rather than at your bug.
What they share is that both demand codified values, not free text. Nationality, document type and municipality are enumerations maintained by the authority, and a guest typing "Italy" into a country box produces a record that will be refused. Whatever the guest sees, the system has to resolve it to the official code before submission.
Collect once, file per authority
The workable design is to keep one internal representation of a guest — the fields both authorities need, in your own vocabulary — and to have each provider render that into its own format at submission time. It keeps the check-in form country-agnostic, and it means adding a third country is a new renderer rather than a new data model.
Store the authority's reference when it comes back. That reference is what turns "we submitted it" into "it was accepted", and it is the only thing you can show an inspector. In Boris, a step with the authority's own evidence attached is marked verified, separately from merely having succeeded.
Then delete what you no longer need
Filing is also what ends your basis for holding the guest's document photograph. Once the stay has been filed, the image has done its job. Boris destroys those photographs at that moment, and at the end of the arrival day regardless — see the guide on QR check-in for why that is deliberately not configurable.
What to check in any system that claims to do this
- Does filing retry automatically, at least hourly, without anyone noticing it failed?
- Is a stay that was never filed visibly missing, or just absent from a log?
- Is the authority's reference stored, or only the fact that a request was sent?
- Are nationality, document type and municipality resolved to official codes?
- Does a manual, desk-completed check-in produce the same filing as the automatic one?
- Are document images destroyed once filing succeeds?
Frequently asked questions
How long do you have to file a guest?
The deadline runs from arrival, not from checkout. Italy currently requires communication within 24 hours, or within six hours for stays shorter than 24 hours, and the requirement applies per guest rather than per booking. Rules change, so confirm the current ones with the authority before relying on any implementation.
Can filing run as a nightly batch?
No, and that is the point of the deadline. A guest arriving at 18:00 on Friday cannot wait for whatever runs on Monday, filing inline and hoping loses the record when the endpoint is down, and showing an error is useless because the person who would read it has gone home. What the deadline demands is a queue with retries running at least hourly, plus a record of what was filed, when, and with what reference.
Are SES.Hospedajes and Alloggiati Web variations on one integration?
No, and abstracting them too early gets both wrong. SES.Hospedajes is SOAP whose payload travels as a compressed archive inside the envelope; Alloggiati Web takes fixed-width records of exactly 168 characters, where a field one character short shifts everything after it. What they share is codified values: nationality, document type and municipality are authority enumerations, so a guest typing “Italy” into a country box produces a record that is refused.