Open Api

General Requirement

The RatePilot Open API provides integration endpoints for external systems to synchronize data with the RatePilot platform.

The Open API currently includes three primary synchronization services:

• Master Data Integration — synchronizes hotel and property master data such as companies, rooms, rates, agents, guest profiles, and POS-related entities.
• Reservation Integration — synchronizes reservation data from external systems into RatePilot.
• Room Inventory Integration — synchronizes room availability, inventory, and related room statistics into RatePilot.

The authentication mechanism and common response behavior documented on this page apply to all three Open API synchronization services.

Authentication

Every Open API request must include the partner Client Id and API key as request headers:

x-client-id: <your-partner-client-id>
x-api-key: <your-partner-api-key>

Request Envelope

Every call uses the same three-field envelope, regardless of module:

{

"module": "module",
"data": [ ... ], 
"chunk_metadata": { ... }  
}

Field	Type	Required	Description
module	string	required	One of the module names listed
data	object or array	required	A single JSON object for module / initialization_module; a non-empty array objects for evry other module.Sending the wrong shape for a module is rejected with 400.
chunk_metadata	object	required	present on every request, chunkedor not. See Chunking. Missing it entirely is rejected with 422.

Module Behavior

Each module supports two synchronization modes:

• Initialization: Use initialization_<module_name> for the initial data synchronization.
• Sync: Use <module_name> for ongoing updates data synchronization.

If an initialization module is sent again after the data has already been initialized, the existing data is replaced with the newly submitted data. Related modules must then be initialized again.

Example

For the company module:

Process	Module value
Initialization	initialization_company
Sync	company

Chunking Large Syncs

chunk_metadata is required on every request, not just chunked ones. GuestPro uses it to trace which chunk of which sync a failure belongs to, and it's how your processing_id gets set (see Responses & errors). If a module's full dataset is large (e.g. an initial backfill of thousands of rooms), split it into multiple requests and give every chunk the same process_id so they can be traced as one sync run.

{
  "process_id": "a5f3c9e0-...",
  "chunk_sequence": 1,
  "is_last_chunk": false,
  "total_records_in_chunk": 500
}

Field	Type	Required	Description
process_id	string	Yes	Your own ID, shared by every chunk of one sync run.
chunk_sequence	number	Yes	1-based position of this chunk.
is_last_chunk	boolean	Yes	true only on the final chunk.
total_records_in_chunk	number	Yes	Record count in this chunk's data.

All four fields are required whenever chunk_metadata is included — and it must be included on every request.

For an ordinary, single-request sync (not actually split into chunks), just fill them in as if it were a one-chunk sync:

• chunk_sequence: 1
• is_last_chunk: true
• total_records_in_chunk: set to how many records are in this request's data
• process_id: set to whatever ID you want to use to look this request up later

Responses & errors

Every response from this API — success or error, on this endpoint or any other — uses the same envelope:

{
  "status": 202,
  "success": true,
  "message": "...",
  "data": { ... },
  "errors": [ ... ]
}

Field	Description
status	Same value as the HTTP status code.
success	true for a successful response and false for an error response.
message	Human-readable summary.
data	Present only on some successful responses that return a payload.
errors	Present only on 422 responses — one entry per invalid field.

errors is omitted unless the response is a 422.

data is omitted only for the two errors that happen before your request is even looked at (401, 422). Every other response, success or error, includes a processing_id in data.