API or webhook
Use a stable read or write contract with explicit retries, idempotency and reconciliation.
Selected only when access and failure behavior are evidenced.
Product / Integrations
Keep each system authoritative. Connect only what improves the stay.
Tamaga can provide an owned Drupal-native direct-booking foundation or work around the PMS, booking engine, channel manager, RMS and payment provider the hotel already uses. Integration starts by naming who owns each fact, decision and write.
Choose how Tamaga begins
Begin with an owned foundation or the stack already transacting the stay.
Tamaga-native foundation
An owned Drupal-native direct-booking foundation for a property without an established booking engine, or one deliberately choosing a Tamaga-owned path.
- Provides: A Drupal-owned hotel model, guest path, Room Fit, governed requests, Host Attention, and optional CRM, Guest Memory, and House-scoped intelligence layers.
- Keeps authoritative: Selected reservation, payment and distribution providers retain their assigned transaction boundaries.
- Production boundary: The public Demo stops before real reservation placement and payment.
Connected Tamaga
A governed hotel-knowledge and request layer around transactional systems the property already trusts.
- Provides: Governed hotel meaning, guest context, visible requests, Host Attention, representation evidence, and optional CRM, Guest Memory, and House-scoped intelligence layers.
- Keeps authoritative: The PMS, booking engine, channel manager, RMS and payment provider retain the functions they own.
- Production boundary: Connections are limited to the smallest evidenced read, write or handoff.
Establish the authority boundary
Name who owns the fact, decision and write before choosing how to connect it.
Three territories show who transacts, where consequential meaning is governed, and where a guest or host decides. Only systems a property actually uses belong in the detailed ownership reference below.
transact
External reservation authority
- Availability and rates
- Reservation state
- Payment and settlement
Keep meaning
Governed House Record
Tamaga governs consequential room meaning without becoming the transaction ledger.
- Conditions and limitations
- Room Fit reasoning
- Sources, owners, review state
decide
Guest and host action
- Understand the stay
- Request and confirm
- Inspect and resolve
One owner per consequential fact.
Availability, meaning, reservation state and settlement each retain a named authority.
No silent authority fallback.
Missing, stale or unavailable state becomes visible instead of being replaced with an unsupported answer.
Every handoff leaves inspectable evidence.
Guest context, responsible ownership and the external outcome remain available for resolution and review.
Optional product layers
Connect records without collapsing their authority.
CRM bridge
The bridge is asynchronous and failure-isolated: a CRM failure cannot break authoritative booking. Ambiguous identity requires an operator link rather than a silent merge.
Guest Memory
Guest Memory serves operational purpose only. There is no automatic promotion or cross-House portability; missing or stale scope fails closed.
Tamaga Intelligence
Tamaga Intelligence reads public House claims, partitions by House before ranking, rejects stale or unpublished claims at read time, and demotes safely on provider or model drift with no silent failover.
One connected journey
Keep transaction authority visible from decision to later inspection.
The guest decision happens in Tamaga, an external system transacts, and the consequential condition remains available for resolution and inspection.
- Tamaga context
1. Decide in Tamaga
Guest sees Room Fit, limits, and a conditional request path.
- External authority
2. Transact externally
The booking authority owns availability, reservation state, and payment.
- Human resolution
3. Preserve and resolve
Tamaga keeps the condition legible for the guest, host, and later inspection.
Passing context is not transaction success.
A deep link is not reservation confirmation.
Returning a reference is not universal write-back.
External failure cannot be displayed as success.
Implementation reference
Choose the narrowest evidenced connection for the property’s real stack.
Technical detail remains available without competing with the authority model and connected stay.
Common stack patterns
Tamaga-native direct booking
- Authority retained
- Tamaga owns the hotel model and guest path; selected production providers retain their assigned transaction boundaries.
- Tamaga adds
- One governed Drupal foundation for room meaning, fit, conditions, requests and Host Attention.
- Safest start
- Define the property’s reservation, payment and distribution boundary.
- Access boundary
- Property operating decisions and provider access are required before production release.
PMS-led all-in-one suite
- Authority retained
- The suite retains live availability, rates, reservation state and the functions it already transacts.
- Tamaga adds
- Governed room meaning, guest context, request state and accountable human attention.
- Safest start
- Begin with the smallest read or handoff around one consequential promise.
- Access boundary
- Property and vendor access determine whether the boundary can be live, exported or manual.
Modular PMS + booking engine + channel manager
- Authority retained
- Each system keeps its documented reservation, booking and distribution responsibility.
- Tamaga adds
- A House Record and guest-to-host context that survive movement between those systems.
- Safest start
- Map one room, rate or request identifier across the necessary handoff.
- Access boundary
- Stable identifiers and access to each relevant contract are required.
PMS + channel manager + RMS
- Authority retained
- The PMS, channel manager, RMS and specialist systems retain their distinct operational decisions.
- Tamaga adds
- Governed meaning and decision context without silently overriding pricing or specialist state.
- Safest start
- Start read only around the decision whose context is being lost.
- Access boundary
- Vendor access and an explicit ownership map are required before any write.
Limited-access or manual stack
- Authority retained
- Existing records and responsible people remain authoritative.
- Tamaga adds
- A reviewed knowledge layer, visible request state and controlled human handoff.
- Safest start
- Use reviewed export/import or a documented manual handoff.
- Access boundary
- If vendor access is unavailable, the dependency is documented rather than replaced with an invented connector.
Connection methods
Use the narrowest connection that makes the next guest or host decision safer.
Reviewed export/import
Use a reviewed batch boundary when real-time access is unavailable or unnecessary.
Useful for staged migration, governed refresh or read-only proof.
Prefilled deep link
Carry context into the system that owns the consequential action without claiming completion.
A handoff, not reservation confirmation.
Embedded flow
Keep the decision close to the guest journey while the embedded system remains authoritative.
Requires a deliberately scoped transaction and failure contract.
Controlled human handoff
Make the responsible human step visible when a safe technical connection is unavailable.
Valid for pilots, exceptions and limited-access stacks.
Connect honestly, fail visibly.
A safe handoff is better than a false success.
Unavailable read
Show clearly labelled last-known state or block the action.
Unavailable write
Use read-only mode or hand off.
Unknown transaction result
Require reconciliation.
Missing room or rate mapping
Fail closed.
Stale authority
Make no new consequential projection.
Vendor access unavailable
Document the dependency rather than inventing an integration.
Ambiguous contact identity
Require an operator link; do not merge contacts silently.
CRM synchronization unavailable
Preserve the authoritative booking and reconcile the context later.
Guest Memory scope or review unavailable
Do not apply the memory.
Intelligence qualification or provider drift
Use deterministic fallback, demotion, or temporary unavailability; never fail over silently.
Describe only the evidenced scope.
Tamaga does not currently publish a universal connector catalogue.
A status describes one evidenced scope. It never implies support for every property, workflow or vendor version.
- Production
- Operating live within one evidenced contract and verified failure boundary.
- Pilot
- Evaluated within named scope, review and rollback conditions.
- Adapter available
- A reusable technical adapter exists; the property connection still requires validation.
- Custom connection
- A deliberately scoped implementation is required for the property or vendor.
- Handoff
- Tamaga carries context to the system or person that owns the action.
- Read only
- Tamaga can inspect or explain state without changing the source system.
- Vendor access required
- Progress depends on vendor-held access, approval or contract.
Continue the mesh
Follow the next useful relationship.
Start with the real stack
Connect the smallest boundary that resolves one consequential problem.
Show Tamaga the systems, ownership boundaries and guest promise involved. The first step is to decide what should remain authoritative, rather than replace everything.