Integrations & platform
What we connect to, stated plainly.
Three levels, and we do not move anything up a level before it is true. If you are evaluating us as a development partner, this page is written for you — every claim below can be checked with the vendor named.
Level 1
Running in production
In daily use across live properties and stores. Credentials configured per tenant, encrypted at rest.
- In useMollieCard, iDEAL and SEPA payments, with webhook reconciliation that never trusts the browser redirect.
- In useM-Pesa (Safaricom Daraja)STK Push in Kenyan shillings, sandbox and production, idempotent callbacks.
- In useSMTP2GOTransactional and campaign e-mail, with open, click and bounce tracking on our own endpoints.
- In useTwilioSMS and WhatsApp, via an API key rather than the account token so it can be revoked on its own.
- In useCloudflareDNS and object storage per tenant, provisioned from the admin panel.
- In useGoogle Analytics & Search ConsoleAnalytics 4 and Search Console through OAuth, per property.
Level 2
Built, awaiting certification or credentials
The adapter exists, is covered by tests and follows the vendor's published API. What is missing is the vendor's own certification step or a production key — not the code. We name these separately because calling them live would not be true.
- ReadyChannex.ioChannel manager: availability, rates and reservations. Built against the public API; certification with Channex not yet completed.
- ReadySiteMinderChannel manager and the TheBookingButton rates feed. Adapter complete, awaiting partner credentials.
- ReadyBeds24Channel manager via refresh-token authentication. Adapter complete, not yet run against a live property.
- ReadyCubilis (Stardekk)Stardekk channel manager. Adapter complete, not yet run against a live property.
- ReadyiBelsaProperty management system, read-only. Built for a live customer; awaiting their API key.
- ReadyStripeCard payments with signed webhooks, as an alternative to Mollie.
Level 3
Built on request
Nothing exists here yet, and we are not going to pretend otherwise. What does exist is the architecture to add it and a track record of doing so. If you supply one of these systems, the section below is the part worth reading.
- On requestDoor locks and key cardsEncoding a card at check-in, revoking it at check-out, and writing every issue to an audit trail. We have not shipped this yet and name no vendor we have not spoken to.
- On requestLift control and floor accessReleasing a guest's floor for the length of their stay, tied to the same reservation that drives the lock.
- On requestPayment terminalsCard-present payment at the desk and the restaurant, settled against the same folio as the room.
- On requestRoom energy and climateSwitching a room down when it is empty and back up before arrival, driven by the reservation.
How we build them
Why a new integration is a week, not a quarter
Every external system is an interface in the domain core with a concrete adapter in the application. Which adapter a property uses is configuration, not a code change — so adding a vendor never touches the booking, billing or tax logic.
Ports and adapters
Payments, invoicing, e-mail, channel managers and property systems are each an interface with swappable implementations. A new vendor is a new adapter, not a fork.
One tenant, one boundary
Every record carries its property. A background job reconstructs that context per task and never inherits it from a request, so a webhook cannot write into the wrong property.
Credentials encrypted per property
API keys are stored encrypted with AES-256-GCM and decrypted only where they are used. No shared account across customers.
Idempotent by default
Webhooks and callbacks can arrive twice, out of order, or after the customer already closed the tab. Reconciliation re-reads authoritative state from the vendor rather than trusting the message.
Tested, and gated on every push
Four gates run on every commit and before every deploy: architectural invariants, domain unit tests, application tests and a production build. A rule we agree on becomes a test, not a comment.
A documented API
A versioned HTTP API with webhooks for the events an external system cares about — arrival, departure, room change, cancellation. We will send the specification before the first call.
Availability
What we commit to
99.9%
Availability target for the hosted platform, measured monthly. Planned maintenance is announced in advance.
ISO 27001 infrastructure
The platform runs on infrastructure certified to ISO 27001. KaribuOne itself holds no certification, and we are not going to imply otherwise.
Someone in your time zone
Support and engineering in Kenya, reachable during Kenyan business hours rather than a queue in another hemisphere.
We list only what we can evidence. If you need something stated here formally — a data processing agreement, a security questionnaire, a penetration test report — ask us and we will tell you honestly what exists today and what does not.
Evaluating us as a partner?
Tell us which system you supply and we will send the specification, the adapter approach and a realistic date — including the parts we would have to build first.