Skip to main content

How it is planned to be integrated with companies

Booker4j is designed so that companies can plug it into their own systems and channels without rewriting core booking logic.

Tenant and configuration​

  • Per-customer setup — Each company (or brand, product line) is treated as a distinct customer/tenant. Access control, form configs, and knowledge bases are scoped per customer.
  • Configuration per tenant — Forms, prompts, and knowledge bases are organised by customer ID. Deployments can serve multiple tenants with different configs.
  • No shared data between tenants — Session and form data are isolated by customer so one company’s data is never mixed with another’s.

Deployment model​

  • API-first — The core is an API that accepts chat messages and returns assistant replies and form state. Companies integrate by calling this API from their own front ends or channel adapters.
  • Channel adapters — Companies can put their own adapters in front of the API (e.g. for RCS, SMS, WhatsApp, Facebook Messenger). The adapters translate channel-specific formats into the same API calls and responses.
  • Hosting — The API can be hosted by the product team or by the company, as long as the company’s systems can reach it and the security layer (e.g. Keystone) is correctly configured for that customer.

What companies need to provide​

  • Identity and access — Integration with the chosen security layer (e.g. OAuth/JWT and customer resolution) so that each request is tied to a valid customer.
  • Channel integration — If they use RCS, SMS, WhatsApp, or Messenger, they (or a partner) implement the adapter that talks to the Booker4j API and the channel’s API.
  • Content — Form definitions, copy, and knowledge-base content for their services and policies.

In short: companies get a stable, config-driven booking API and plug it into their channels and identity systems; they do not need to own the form or chat engine logic.