Start with a sandbox. Move to production when you are ready.
Sign up in the Portal, create an organisation, open a sandbox. When you need production, join the waitlist.
Sandboxes run on staging with test data. Production access is by waitlist.
BookingHash
The bookings engine with a hash-chained diary. Sandbox on staging
Availability decisions, holds, bookings and lifecycle events, each recorded as an event in a per-booking SHA-256 hash chain that your systems can verify on demand.
How a booking becomes a record
The lifecycle is a state machine. Each fact writes an outbox event in the same database transaction, so the record and the history cannot drift apart.
-
Request
A client asks for capacity: a room, a table, a slot, a piece of equipment.
-
Availability decision
A pure, in-memory recipe decides. It is not a stored state; nothing is written until a hold is placed.
-
Hold
An active hold reserves the capacity for a bounded time.
-
Booking
The hold becomes a booking: requested and pending approval, or confirmed.
-
Lifecycle events
Start, complete, cancel, no-show, modify. Each is an event in the chain.
One booking, one chain
Every event is a row in a per-aggregate SHA-256 hash chain: the hash covers the tenant, the previous event hash, the id, the aggregate, the sequence, the type, the time and the canonical payload. The head is GENESIS, the sequence is gapless, forged hashes are refused at insert, and updates or deletes are blocked by triggers.
BookingHash: one booking, one chain
Illustrative digests- A request for Room 12 for 2 nights arrives; the availability decision is computed in memory and not stored.
- Event 1, hold placed, is sealed with the previous hash GENESIS.
- Event 2, booking confirmed, is sealed with the hash of event 1.
- Event 3, started, and event 4, completed, follow, each sealed with the previous hash.
- Verification walks the chain and recomputes every hash: CHAIN_VALID.
- Event 2's payload is altered to 3 nights: its recomputed hash differs, the links after it fail, verification reports CHAIN_BROKEN at sequence 2.
Request Room 12 · 2 nights Availability decision In memory · not stored
- seq 1 Hold placed Room 12 · 2 nights prev GENESIS hash a91c…4e2f
- seq 2 Booking confirmed Room 12 · 2 nights Room 12 · 3 nights prev a91c…4e2f hash 3f9a…b071 e07b…52c1 recomputed
- seq 3 Started Check-in recorded prev 3f9a…b071 hash c4d8…19aa
- seq 4 Completed Stay completed prev c4d8…19aa hash 7be0…d35c
Sealing events Walking the chain An earlier event is altered CHAIN_VALID · 4 events CHAIN_BROKEN at sequence 2
Every event is hashed with the previous hash (SHA-256). Change one, and every later link fails verification.
Optional: a daily digest per tenant can be written to storage with Object Lock in compliance mode (write-once anchoring), enabled per tenant.
What the API gives you
-
Deterministic verification
GET /v1/bookings/{id}/history returns the diary plus chainValid. The database walks the chain and recomputes every hash; an altered earlier event yields CHAIN_BROKEN at that row.
-
Idempotent writes
Send an Idempotency-Key with every write. A retried request returns the original outcome instead of creating a duplicate.
-
Sandbox and live keys
Sandbox keys are prefixed bh_test_, live keys bh_live_. The key is the tenant address; an unknown key receives a uniform 401.
-
Write-once anchoring (optional)
A daily digest per tenant and day, chained day to day, can be written to storage with Object Lock in compliance mode. Anchoring is enabled per tenant and vault verification has no public HTTP endpoint.
Where it fits
Any operation that holds and then confirms capacity: rooms and nights, tables and seatings, appointments, rentals, equipment. BookingHash records the decision and the diary; your product owns the experience.
What we do not claim
- No uptime, latency or volume statistics are published.
- No certification or audit is claimed.
- It is a linear hash chain in a database, not a public network and not a tree structure.
- Hashes cover the canonical event payload; they are a tamper-evident record, not encryption.