API Documentation

Connection details

Example connection types

Keep the API key on the booking system's server. Never place it in browser JavaScript, a mobile app, source control or logs.

A digiGate Pro API or Enterprise licence is required. ANPR bookings also require an ANPR or Enterprise licence.

API Flow Behaviour

• save is an upsert (update or insert). The first request for a booking_reference creates the booking. A later request using the same key and reference replaces the complete booking state.
• Do not send an add/update mode. digiGate Pro determines it internally.
• Always resend every required field and the complete device/access list when updating. Updates are not patches.
• A booking reference belongs to the API-key account that created it. Different integration accounts have separate reference namespaces.
• A deleted booking reference cannot be reused. Use a new reference if the booking is recreated later.
• delete is idempotent. Repeating a delete, or deleting an unknown reference, succeeds as a no-op.

Save a booking

Request

POST <digigate-host>/api/bookings/save HTTP/1.1
Authorization: Bearer <BOOKING_API_KEY>
Content-Type: application/json

The JSON body must contain one data object.

Accepted data

Accepted boolean values are JSON booleans, 0, 1, and the strings "false", "true", "0" and "1".

Choose the access method

Use one of these three values:

For app and GSM bookings, always use:

"access_method": "user"

The app_control and gsm_control fields then determine what access the person receives.

App access only

"access_method": "user",
"app_control": true,
"gsm_control": false,
"control_remotely": true,
"email": "john.smith@example.com"

email is required because the user can sign in through the digiGate app.

GSM access only

"access_method": "user",
"app_control": false,
"gsm_control": true,
"control_remotely": false,
"phone": "+447123456789"

phone is required because the user will use GSM call-to-open.

App and GSM access

"access_method": "user",
"app_control": true,
"gsm_control": true,
"control_remotely": true,
"email": "john.smith@example.com",
"phone": "+447123456789"

Both email and phone are required.

Fields used in the App/GSM access:

Fields used in the ANPR access:

Fields used in the temporary-PIN access:

Do not send max_uses or device notes unless access_method is temp_pin.

Device selection

Select each output by its unique configured device name. This name must match the configured output name in the management console:

{
  "device": "Main Entrance"
}

If preferred, a device can alternatively be selected by receiver ID and output number (found within the management console):

{
  "receiver_id": 12,
  "output": 1
}

output_number is accepted as an alias for output. Do not send both forms for one device, and do not mix device with receiver/output IDs in the same device object.

Only enabled outputs with a name and an open or switch function are bookable. Output-name matching is case-insensitive and must identify exactly one output.

ANPR devices may include:

{
  "device": "Main Entrance",
  "disable_reg_on_entry": true
}

disable_reg_on_entry is per device and makes the individual ANPR access single-use on that output. Do not place it at the top level.

Temporary-PIN devices may override the top-level defaults:

{
  "device": "Pedestrian Gate",
  "max_uses": 4,
  "notes": "Late arrival"
}

Example booking 1: App and GSM access

For every person-based booking, use access_method: "user". The app_control and gsm_control fields determine what the person can use.

{
  "data": {
    "booking_reference": "DG26PRO-10482",
    "booking_alias": "John Smith - Monday to Friday",
    "access_method": "user",
    "name": "John Smith",
    "email": "john.smith@example.com",
    "phone": "+447123456789",
    "app_control": true,
    "gsm_control": true,
    "control_remotely": true,
    "access_type": "calendar",
    "access_start": 1789394400,
    "access_end": 1789725600,
    "devices": [
      { "device": "Main Entrance" },
      { "device": "Car Park Barrier" }
    ],
    "meta": {
      "property_id": 4,
      "source_status": "confirmed"
    }
  }
}

Example booking 2: ANPR vehicle access

{
  "data": {
    "booking_reference": "DG26PRO-ANPR-55821",
    "access_method": "anpr",
    "name": "John Smith",
    "registration": "DG26 PRO",
    "access_type": "calendar",
    "access_start": 1789394400,
    "access_end": 1789725600,
    "devices": [
      {
        "device": "Vehicle Entrance",
        "disable_reg_on_entry": true
      }
    ]
  }
}

To reactivate a consumed single-use ANPR booking, resend the full booking with the same reference and add "reset_consumed": true.

reset_consumed only affects an ANPR booking configured with disable_reg_on_entry: true. Once that booking has been used, digiGate marks the registration as consumed so it cannot open again. Sending reset_consumed: true while updating the booking clears that consumed state and starts a new usable access period. It does not extend the dates, change the vehicle registration or bypass the booking window. Omit it, or send false, for an ordinary ANPR update.

Example booking 3: Temporary PIN access

{
  "data": {
    "booking_reference": "DG26PRO-PIN-9002",
    "access_method": "temp_pin",
    "name": "John Smith",
    "access_type": "calendar",
    "access_start": 1789394400,
    "access_end": 1789725600,
    "phone": "+447123456789",
    "max_uses": 2,
    "notes": "Self check-in",
    "devices": [
      { "device": "Pedestrian Gate" },
      {
        "device": "Locker Room",
        "max_uses": 4
      }
    ]
  }
}

Each selected output receives its own five-digit PIN. Updating the same booking and output preserves its PIN and used_count. Adding another output creates a new PIN for that output. If an output is omitted from a later update, its PIN is deleted. Deleting the booking removes all PINs belonging to it.

Successful save response

The response field is digiGate Pro's application response code. Clients must read the JSON success value and must not rely only on the HTTP status.

{
  "success": true,
  "response": "201",
  "response_description": "The resource was created successfully.",
  "mode": "add",
  "created": true,
  "updated": false,
  "booking_reference_id": 42,
  "booking_reference": "DG26PRO-10482",
  "booking_alias": "John Smith - Monday to Friday",
  "access_method": "user",
  "subject_user_id": 391,
  "subject_created": true,
  "invite_required": true,
  "anpr_refresh_required": false,
  "consumed": false,
  "saved_devices": [],
  "removed_devices": [],
  "saved_pins": [],
  "removed_pins": [],
  "invite_status": "queued",
  "anpr_refresh_status": "not_required"
}

New bookings use application response 201; updates use 200. The exact saved_devices and saved_pins arrays contain the resolved receiver/output records and should be treated as response data, not resubmitted unchanged.

Possible invite_status values are pending, queued, already_sent, not_required and failed. Possible anpr_refresh_status values are pending, updated, not_required and failed.

If a post-commit action fails, the booking still has success: true and includes a warnings array. Do not retry the whole save solely because a warning was returned.

Delete a booking

Request

POST <digigate-host>/api/bookings/delete HTTP/1.1
Authorization: Bearer <BOOKING_API_KEY>
Content-Type: application/json

Data included

{
  "data": {
    "booking_reference": "DG26PRO-10482"
  }
}

booking_reference is required, trimmed, limited to 150 characters and scoped to the authenticated integration account.

Successful delete response

{
  "success": true,
  "response": "200",
  "response_description": "The request has succeeded",
  "found": true,
  "deleted": true,
  "already_deleted": false,
  "idempotent_noop": false,
  "booking_reference_id": 42,
  "booking_reference": "DG26PRO-10482",
  "booking_alias": "John Smith - Monday to Friday",
  "access_method": "user",
  "subject_user_id": 391,
  "access_type": "calendar",
  "subject_disabled": true,
  "remaining_booking_count": 0,
  "removed_calendar_access_count": 2,
  "removed_weekday_access_count": 0,
  "removed_devices": [],
  "removed_pins": [],
  "anpr_refresh_required": false,
  "anpr_refresh_status": "not_required"
}

For an unknown reference, found is false and idempotent_noop is true. For a repeated delete, already_deleted and idempotent_noop are true.

Deleting a booking removes only access owned by that booking. Shared accounts, registrations, permissions and other bookings remain. A subject account is disabled only when no remaining booking requires it.

Application response codes

Error responses normally include success: false, response, response_description, and may include a human-readable reason.

{
  "success": false,
  "response": "811",
  "response_description": "Validation failed",
  "reason": "access_end must be later than access_start."
}

Retry and reconciliation guidance

• Use a stable, unique source booking ID as booking_reference.
• It is safe to retry the same complete save after a timeout because it updates the same active reference.
• It is safe to retry delete requests because deletion is idempotent.
• Store the complete JSON response for reconciliation, but redact the Authorization header.
• Temporary PINs are credentials. Encrypt them at rest, reveal them only to the intended guest and never write them to ordinary application logs.
• Use exponential backoff for transport failures and application response 500. Correct rather than blindly retry validation, permission or licence errors.

Integration checklist

• Obtain a dedicated Booking API key with access only to the two booking endpoints.
• Confirm the target digiGate Pro licence and required ANPR licence.
• Map booking-system IDs to immutable booking_reference values.
• Map configured digiGate output names. Receiver/output IDs are available as an alternative when needed.
• Send all timestamps as Unix seconds in the digiGate Pro system's expected local operating context.
• Exercise create, full update, delete, repeated delete and failure retries on a test system before production.