Registering the PUI query URL
To interconnect with the PUI, a lodging must register a query URL: the endpoint where it will receive and answer the authority’s questions about reported persons. Here we explain what that endpoint is, which security requirements it demands (JWT authentication, TLS encryption, security reports) and why, honestly, a small lodging cannot build it alone.
What the query URL is
The query URL is a web address, technically a REST endpoint, that your establishment registers with the platform. It is the "door" through which the search authority sends its questions and through which your system responds automatically from your guest registry.
The model is a targeted query: the authority asks about a specific person reported as missing (by CURP or name) and your system responds whether that person checked in at your lodging or not. It is not a mass dump of your guests or continuous monitoring: it is answering concrete questions, one by one.
That is why registering this URL is not like setting up an email or a phone number. It is exposing a service that receives queries about sensitive personal data and must respond securely, reliably and verifiably. Hence the technical requirements we’ll see next.
Which security requirements the endpoint demands
Just "having a URL" isn’t enough. The endpoint must meet concrete security locks.
JWT authentication
Each query arrives with a signed token proving the asker has permission. Without that valid token, the endpoint must not respond.
TLS encryption in transit
All communication travels encrypted, like on a secure web page, so no one can intercept or read the data along the way.
SAST reports
Analysis of the service’s source code to detect security flaws before exposing it to production.
DAST reports
Tests on the running service, simulating attacks, to find vulnerabilities under real conditions.
SCA reports
Review of the service’s libraries and dependencies, to rule out components with known vulnerabilities.
Ready before production
These reports are required before going to production: the endpoint must arrive "approved" on security, not improvised.
What registering and sustaining that URL involves
It is not a one-off procedure: it is building and maintaining a service over time.
- Have an available serviceThe endpoint must be online and available to receive queries when they arrive. It cannot be a page that sometimes responds and sometimes doesn’t.
- Protect it with JWT and TLSImplement token authentication and transport encryption correctly. A mistake here exposes sensitive data or blocks legitimate queries.
- Pass the security testsGenerate and approve the SAST, DAST and SCA reports before production, and do it again whenever the software changes.
- Operate and maintain itWatch that it stays available, update dependencies, address security findings. It is continuous operation, not "install it and forget."
Why a small lodging cannot build it alone
Seen as a whole, registering the query URL is not a front-desk task: it is a software project with serious security requirements. You need to develop the service, protect it with JWT and TLS, generate SAST, DAST and SCA reports, keep it available and re-audit it every time something changes.
A small hotel, an inn or a cabin almost never has a technology team able to build and sustain that. And it is not reasonable to expect them to: their business is welcoming guests, not operating security infrastructure. Trying to improvise the endpoint is risky, because we’re talking about sensitive personal data and a compliance requirement.
That is why, honestly, the sensible thing is to rely on a system that already has that endpoint built, protected and maintained, and that registers your query URL for you. That way you meet the requirement without becoming a software company. Remember too that full interconnection is enabled once the government publishes the pending manual; arriving with this solved is the advantage.