Security
How BineBoost protects your data
To use BineBoost 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 BineBoost at all. By default guests pay you directly by bank transfer. You can optionally offer card payment; it then runs through your own Stripe account and the money is credited straight to you. Either way BineBoost never sits between you and your guest, no money flows through us, and we keep nothing back. Guests enter their card exclusively on Stripe's payment page (PCI-DSS certified); all we receive is the amount, the currency and the status of the payment. The amount is only reserved at first and collected once the booking sits in the Smoobu calendar. We never see or store card number, security code or expiry date. The same holds for your own BineBoost subscription.
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. For your guests' card payments Stripe is not our sub-processor: there the contract is between you and Stripe. |
| 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 BineBoost. |
| 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
What this section says about Smoobu comes from our own operation on the API, last measured on 9 September 2026.
| Area | Implementation |
|---|---|
| The API and nothing else | BineBoost talks to Smoobu exclusively through its REST API, never through the interface and never with your Smoobu password. Every request is signed with HMAC-SHA256, using the key pair you enter yourself. If that key pair stops being valid on Smoobu's side, access ends immediately, with nothing for you to do here. |
| No bypassing your system | BineBoost 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. |
| What is stored on your guests' devices | The embedded booking engine sets no cookies and loads no third-party trackers. It stores nothing on your guests' devices, with one exception: if a guest pays by card, their name and email are held for the duration of the trip to Stripe's payment page so the confirmation page can still show them afterwards. That entry is deleted the moment they return to the booking flow and is technically required for the booking. Whether your site as a whole needs consent depends on everything else you embed and on your own privacy notice. That is yours to judge, and worth going through once with whoever advises you on data protection. |
| Traffic measurement | This marketing site counts visits without cookies and without third parties. Visitors are distinguished by a hash of a random value drawn fresh every day, the date, the IP address and the browser string. The random value lives in memory only and is overwritten at the turn of the day, so the stored value can no longer be traced back to an IP address. Raw data is deleted automatically after 90 days. |
| Retention | Bookings are deleted 24 months after departure, offers 90 days after they expire, enquiries 12 months after they arrive. Internal error logs are deleted 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: the booking flow loads asynchronously into its own container and does not block the page around it. Neither your channel connections nor your Smoobu account run through BineBoost; an outage here does not sit in their path. |
| 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-party scripts, no recognition beyond the visit. If a guest chooses card payment, the final step takes them to Stripe's payment page, where Stripe's own terms apply.
- 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 BineBoost account. It is listed openly on the roadmap, like everything else that is not finished yet.
Frequently asked questions
Where is BineBoost data stored?
Servers and database are located in Amsterdam, Netherlands, inside the EU. Core processing involves no data transfer to third countries. The daily backup goes to a separate object store, also inside the EU. Which other providers are involved is set out by name in the data processing agreement. One boundary belongs in the picture: what BineBoost writes into your Smoobu account sits there afterwards and no longer in our systems.
How are my Smoobu API credentials stored?
API key and secret are stored encrypted with AES-256-GCM, never in plain text. The encryption key is held separately from the database, in the server configuration, so the credentials stay unreadable inside every backup. Once entered they only travel one way: no page in the dashboard shows them again, and no interface hands them back out. Delete the connection in the dashboard and they are removed. If the key pair stops being valid on Smoobu's side, access ends immediately, with nothing for you to do here.
Does BineBoost process my guests' card details?
No. By default guests pay you directly by bank transfer. If you also offer card payment, it runs through your own Stripe account and the money is credited straight to you; BineBoost never sits between you and your guest. Guests enter their card exclusively on Stripe's payment page (PCI-DSS certified); all we receive is the amount, the currency and the status of the payment. The amount is only reserved at first and collected once the booking sits in the Smoobu calendar. That does not change with a down payment or a refundable deposit: whatever share of the price you collect before arrival runs over that same Stripe page if the guest pays by card, and no card details reach us there either. How high those amounts should be, and what your terms say about them, is a separate question and worth putting in front of a lawyer once; the guides on the down payment and cancellation policy and on the security deposit go through both.
What does BineBoost provide for GDPR?
A data processing agreement under Art. 28 GDPR including technical and organisational measures and the list of sub-processors, plus EU hosting and a booking flow that sets no cookies and loads no third-party trackers. Whether your site as a whole needs consent depends on everything else you embed and on your own privacy notice; that judgement belongs in a lawyer's hands if there is any doubt.
What happens if BineBoost causes an error?
Server errors are logged, critical cases automatically send an email to the operator, at night and at weekends too. If the booking flow goes down your website stays reachable: the booking flow is embedded asynchronously into its own container and does not block the page around it, whether as a script or as a frame; neither your channel connections nor your Smoobu account run through BineBoost. What I commit to in an incident is written in the SLA. The business also carries professional indemnity cover of €500,000 and public liability cover of €3,000,000 with Hiscox; what a concrete case is covered for follows from the policy wording, not from this page.
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 BineBoost free