Security
How SmooBoost protects your data
To use SmooBoost you hand over the API credentials of your Smoobu account. That is trust you have to earn — so this page states openly what happens technically, concretely enough that you can check it.
The three most sensitive things
If you only read three paragraphs, read these.
-
Your Smoobu credentials
API key and secret are stored encrypted with AES-256-GCM — never in plain text. The encryption key sits separately from the database, in the server configuration. They are decrypted solely to run your own booking engine. They stay encrypted in every backup too: anyone who got hold of the database still would not have your Smoobu keys.
-
Your password
Is never stored, not even encrypted. The database holds only an scrypt hash with a per-account salt (N = 16,384) — a deliberately compute-heavy scheme that makes mass guessing uneconomical. Nothing can be reversed out of it. We cannot look up your password, which is also why we can only ever send you a reset link.
-
Your guests' payment details
Are not processed by SmooBoost at all. Guests pay you directly by bank transfer — SmooBoost never sits between you and your guest, and no money flows through us. Card details for your own SmooBoost subscription are handled exclusively by Stripe (PCI-DSS certified); we never see or store them.
Where the data lives
| Area | Implementation |
|---|---|
| EU hosting | Servers and database are located in Amsterdam, Netherlands. Core processing involves no data transfer to third countries. |
| Transport encryption | All traffic runs over TLS (HTTPS) — including the booking engine embedded on your own website. |
| Sub-processors | Deliberately few, established providers: Railway (hosting, EU), Cloudflare (TLS/CDN), Resend (email delivery), Stripe (subscription payment). The full list is in the data processing agreement. |
| Separation between customers | Every request is bound to one account. Access to another account's properties, bookings or settings is rejected server-side — not merely hidden in the interface. |
Securing the application
| Area | Measure |
|---|---|
| Sessions | The login cookie is HttpOnly (no JavaScript access), SameSite=Lax and Secure (HTTPS only). The database stores not the token itself but only its SHA-256 hash. |
| SQL injection | All database access goes through a typed ORM (Drizzle) with parameterised queries without exception. Input is never interpolated into SQL strings. |
| CSRF protection | Every state-changing request checks the Origin header against a fixed allow-list; foreign origins are rejected with 403. |
| Abuse limits | Sign-in, registration, password reset and verification are rate-limited per IP address. So are the booking engine's public endpoints — roughly 30 searches per minute and 12 booking attempts per hour per IP. That also protects your Smoobu account: it cannot be flooded with requests through SmooBoost. |
| Input validation | All dashboard input is validated server-side on a whitelist principle: known fields only, hard length and value limits, enforced data types. |
| Price verification | Prices are recalculated from your live rates on every request and re-checked server-side before a booking is created. A price manipulated in the browser is not accepted. |
| Error messages | Only neutral messages go out — no internal details, stack traces or database contents. |
The Smoobu connection
| Area | Implementation |
|---|---|
| Official API only | SmooBoost uses exclusively the official Smoobu REST API, with HMAC-signed requests and only with keys you generated yourself inside your Smoobu account. You can revoke them there at any time. |
| No bypassing your system | SmooBoost is not a PMS and not a channel manager. It writes bookings into Smoobu and reads availability and rates — it does not change calendar, channel or account settings. |
| Gentle access | Availability and rates are cached briefly so your booking engine does not put unnecessary load on the Smoobu API. Timeouts are caught and shown to the guest as a friendly message. |
| Revoking access | Delete the connection in the dashboard and the encrypted credentials are removed. Whenever a Smoobu account is newly connected or its credentials change, you automatically receive a notification email — so you notice even if it was not you. |
Privacy
| Area | Implementation |
|---|---|
| Data processing agreement | A data processing agreement under Art. 28 GDPR is available, including technical and organisational measures and the list of sub-processors. |
| Guest data | Collected solely in order to create the booking in your Smoobu account, and passed there. No resale, no profiling, no marketing to your guests. |
| No cookies in the booking flow | The embedded booking engine sets no cookies and loads no third-party trackers. It therefore triggers no consent requirement on your website. |
| Traffic measurement | This marketing site counts visits without cookies and without third parties, using a daily rotating hash that cannot be traced back to an IP address. Raw data is deleted automatically after 90 days. |
| Retention | Internal error logs are deleted automatically after 60 days. When an account is closed its data is removed, encrypted Smoobu credentials included. |
Operations, backups and worst case
| Area | Implementation |
|---|---|
| Backups | Automatic daily database backup, in addition to the hosting provider's own backups. A compressed copy also goes to a separate object store inside the EU — kept next to the data only, it would be gone along with the server. Encrypted credentials stay encrypted inside the backup. |
| Error alerting | Server errors are logged and linked to what triggered them; critical cases automatically send an email to the operator — at night and at weekends too. Problems are not first noticed when someone phones. |
| Availability | An independent external service checks every five minutes that the application and its database respond — the history is open to inspect on the status page. During updates the service is shut down in a controlled way so in-flight requests finish cleanly. |
| If the booking engine fails | Your website stays up — what you embed is an iframe, not a script that could block your page. Your channel connections and your Smoobu account keep running entirely independently. |
| Insurance | The business carries professional indemnity cover of €500,000 and public liability cover of €3,000,000 with Hiscox — a policy for advertising, marketing and PR agencies, extended to cover software and hardware. |
- No storage of card details — neither yours nor your guests'.
- No plain-text passwords, no plain-text Smoobu credentials.
- No resale and no sharing of data with third parties for advertising.
- No tracking of your guests in the booking flow — no cookies, no third parties.
- No access to parts of your Smoobu account the booking engine does not need.
What comes next: an optional two-factor sign-in for your SmooBoost account. It is listed openly on the roadmap — like everything else that is not finished yet.
Still a question open?
I answer security questions personally and concretely, including the technical ones. If your data protection officer needs more depth than this page offers, just write to me.
Try SmooBoost free