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.

Booking submission​

Once a booking is confirmed, Booker4j can submit it to the company's own backend or external system. This is configured per customer using pluggable providers and converters.

Confirmation messages shown to the user after submission are not hardcoded — each customer has configurable translation keys (success-message-key, failure-message-key) that are resolved per locale at runtime. The LLM then composes a natural response using the resolved message. This means different customers can show different confirmation messages, and all messages are automatically localized.

See Booking Submission for full details on configuration, translation keys, and how to extend with new providers.