An API for the same platform you use

OverviewComing soon

A REST API that returns JSON. Every path starts with /api/v1.

• The version is in the path. Any breaking change gets /api/v2, living next to v1
• Dates use ISO 8601 and are stored in UTC
• Each property has a time zone and stays are computed in it
• Messages follow the Accept-Language header, Arabic or English
• We send the OpenAPI description to integration partners

GET https://{your-domain}/api/v1/orgs/{orgId}/properties
Accept: application/json
Accept-Language: ar

Authentication modelComing soon

Each kind of user has its own way in and its own permissions.

Staff sessionDesigned

The console uses a server-side session in a protected cookie. Sessions expire and can be revoked, with protection against forged requests.

Guest linkDesigned

A token bound to one reservation with limited permissions. Fully separate from staff accounts.

Property API keysComing soon

Keys per account with scoped permissions for connecting your own systems.

Account isolationDesigned

Every property account is isolated from the others on every request.

• The account ID is in the path, such as /orgs/{orgId}
• The server checks the user is a member of the account before anything else
• The account is never taken from the request body
• The database itself rejects rows from another account
• Requesting a resource from another account returns not found

ResourcesComing soon

The core resources of the API.

Requests and errorsComing soon

General rules for every request that changes data.

• An Idempotency-Key header prevents duplicates when you retry the same request
• A booking conflict returns 409 with a clear error code
• Every error response has a code, a message and a request ID for follow-up
• Rate limits apply, and exceeding them returns 429

POST /api/v1/orgs/{orgId}/reservations
Idempotency-Key: 5b1f0c1e-7a7e-4f2b-9d0e-1f6c2b9a4e11
Content-Type: application/json

{ "propertyId": "...", "bedId": "...", "checkIn": "2026-11-02", "checkOut": "2026-11-05" }

HTTP/1.1 409 Conflict
{ "error": { "code": "bed_unavailable", "message": "...", "requestId": "..." } }

Event notificationsComing soon

The system records every important change as an event. Later you will be able to subscribe and receive events on your server.

• Every event has a stable ID. Use it to ignore duplicates
• Delivery is at least once. The same event may reach you more than once
• Each request is signed with a secret unique to the subscription
• Retries with backoff if your server does not reply with success
• Internal network addresses are not allowed as destinations

Example events

• reservation.confirmed
• reservation.cancelled
• stay.checked_in
• stay.checked_out
• payment.verified
• task.completed
• access.credential.confirmed

POST https://your-server.example/hooks
X-Event-Id: evt_...
X-Signature: t=...,v1=...
Content-Type: application/json

{ "type": "reservation.confirmed", "occurredAt": "...", "data": { "reservationId": "..." } }

Devices and providersComing soon

Locks and payment providers connect through connectors inside the platform. You do not write them yourself.

• Each connector declares device capabilities such as temporary PIN or remote unlock
• Command state goes pending, sent, received, then confirmed, failed or unknown
• The trial hostel uses test connectors only
• The status of each vendor is on the devices and integrations page