Network requirements
This page is for the network and security team of an organization that uses HotLayout from a restricted network. It lists every connection the product makes, from where to where, and what travels over it, so the allowlist can be written once.
Related pages: index · embedding · delivery · backend guide
Summary#
| Who | Connects to | Direction | Needed for |
|---|---|---|---|
| Browsers of the people who build screens | hotlayout.com and four Google API hosts |
outbound, HTTPS 443 | the editor and the admin |
| Your backend, if you embed the editor | hotlayout.com |
outbound, HTTPS 443 | asking for a session ticket |
| HotLayout, if you take publications by webhook | your webhook endpoint | inbound to you, HTTPS 443 | delivering a published document |
| The mobile or web app of your customers | either the HotLayout storage host or your own servers | outbound, HTTPS 443 | reading published screens |
Everything is HTTPS on port 443. There are no WebSockets, no long-lived streaming connections and no other ports.
What travels over these connections#
A document is a layout: widgets, texts, colours, and data paths such as user.balance. The values for those paths are filled in by your app on the device, from your own backend. The editor shows the sample values of your data dictionary, never your customers' data.
So what leaves your network when someone builds a screen is the screen itself, the theme and the images used in it — not customer records, balances or personal data of your customers. What the editor does store about the people who build screens is their email, name and role, for sign-in and for the members list.
Browsers of the people who build screens#
Allow these hosts for the workstations that open the editor or the admin:
| Host | What it serves |
|---|---|
hotlayout.com |
the admin, the editor module (/embed/v1/), the documentation, and the API under /api/ (session exchange, export) |
firestore.googleapis.com |
organizations, projects, members, document records |
firebasestorage.googleapis.com |
drafts, published documents, themes, images |
identitytoolkit.googleapis.com |
sign-in |
securetoken.googleapis.com |
renewing the sign-in session |
That is the complete list. Fonts and icons are served from hotlayout.com; the product loads nothing from other CDNs, analytics or advertising hosts. The browser talks to the Google hosts directly, so a proxy that inspects TLS must let these hosts through without replacing their certificates, or the browser refuses the connection.
The product overview video on the landing page is the one exception: it loads from YouTube, and only when someone presses the button. Nobody needs it to work.
Your backend, if you embed the editor#
When the editor is embedded in your own admin (see embedding), your backend asks for a session ticket:
| From | To | Request |
|---|---|---|
| your backend | https://hotlayout.com/api/embed/session |
POST, with your embedding key |
The page that embeds the editor needs the same five hosts as above in the browser of the person who opens it. The ticket exchange happens from that browser to https://hotlayout.com/api/embed/exchange.
Publications delivered by webhook#
If you take published documents by webhook (see delivery), HotLayout connects to your endpoint:
| From | To | Request |
|---|---|---|
| HotLayout | your HTTPS endpoint | POST, user-agent: Hotlayout-Webhook/1, signed body |
Webhook requests do not come from a fixed set of IP addresses, so the endpoint cannot be allowlisted by source address. The signature is what proves a request is ours; the user-agent value is a constant you may use in a firewall rule, but it is not proof of origin. The endpoint must have a public IPv4 address (an A record): we do not deliver into private networks.
With webhook delivery your apps read published screens from your own servers, and they never connect to HotLayout at all.
The apps of your customers#
Two ways, chosen by you:
| Delivery | What the app connects to |
|---|---|
| reading published files directly | firebasestorage.googleapis.com |
| webhook to your backend | only your own servers |
The apps run on your customers' devices, outside your restricted network, so this choice is about where your screens are served from, not about your allowlist.
When no outbound connection is allowed at all#
If the workstations that build screens cannot reach any of the hosts above, the cloud product cannot work in that network. Two ways forward:
- export and import: a document can be exported as JSON where the editor is available and brought into your network by your own channel;
- an editor installed in your network that stores documents on your own servers, with an offline licence key. This is offered as part of an enterprise agreement; write to contact@hotlayout.com to discuss it.