Accordly

Developers

Built for a backend, verified by a query.

Both engines are tenant-scoped HTTP APIs. Your sandbox on staging is the reference: create one in the Portal, call the staging API with your test key.

Start a free sandbox Sign in

The shape of a verification call

GET /v1/bookings/{id}/history
Authorization: Bearer bh_test_…
{
  "chainValid": true,
  "events": [
    { "sequence": 1, "type": "hold.placed",        "eventHash": "a91c…" },
    { "sequence": 2, "type": "booking.confirmed",  "eventHash": "3f9a…" }
  ]
}

Illustrative request and response shape; digests are placeholders.

  • Keys and environments

    One key per tenant per environment. BookingHash: bh_test_ and bh_live_. LedgerHash: lh_test_ and lh_live_. Sandboxes exist only on staging; production keys exist only after waitlist onboarding.

  • Idempotent writes

    Send an Idempotency-Key header with each write to BookingHash. Retrying the same request returns the original outcome.

  • BookingHash history

    GET /v1/bookings/{id}/history returns the booking diary and chainValid. The chain is recomputed in the database on every call.

  • LedgerHash proofs and verification

    GET /v1/verify/entry/{id}/proof returns a Merkle inclusion path. /v1/verify/* re-derives payloads and returns the first mismatch; an empty result means intact. GET /v1/verify/anchor/{code} verifies an anchor record.

  • Server-side only

    Call the engines from your server. Never ship a key to a browser or a mobile app.

  • Rate limits and resets

    Sandboxes may be rate-limited and reset. Treat staging data as disposable.

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.

Start a free sandbox Join the production waitlist

Sandboxes run on staging with test data. Production access is by waitlist.