Property Resources
Approved interfaces may make relevant hotel or property information available where required by the integration.
Webhooks & API
Connect Applications with Structured Hotel Data.
Use supported HotelConnect24 APIs and webhook events to build approved system-to-system workflows around hotel data, bookings and connected operations. Access depends on the interface, permissions and functionality available for your integration.
Developer Interface
Illustrative API Workflow
Request → Response → Event
Controlled Access
API Request
Illustrative
AUTH
approved application credentials
GET
/supported-resource
{
"resource": "supported-data",
"status": "available"
}
"resource": "supported-data",
"status": "available"
}
Webhook Event
Illustrative
EVENT
supported.webhook.event
Access
Permission Based
Data
Structured
Events
Where Supported
Example only. Actual routes, methods, schemas, authentication,
webhook events and permissions depend on the HotelConnect24
interface provided for the specific integration.
API Access
Structured resources where supported
Webhook Events
Event-driven workflows where available
Controlled Permissions
Access aligned with the approved use case
Production Testing
Verify complete workflows before launch
API Model
Requests Should Be Predictable. Responses Should Be Understandable.
A useful API is not only about exposing data. The application needs to understand what it is requesting, what the response means and what to do when the request does not succeed.
✓
Use supported resources
Build only against resources available to the approved integration.
✓
Validate input
Applications should send the fields and formats expected by the interface.
✓
Read the response
Do not assume that receiving an HTTP response means the requested action succeeded.
✓
Handle errors explicitly
Connected software should react safely to invalid requests and unavailable services.
Request
Response
Method
Method depends on the supported resource and operation.
Route
/supported-resource
Access
Appropriate authentication and permissions are required.
Payload
Request fields depend on the applicable interface specification.
Result
Applications should evaluate status, returned data and error information.
API Capabilities
Use the Interface Available to Your Integration.
HotelConnect24 developer capabilities can differ by integration. The current technical specification defines what a connected application can read, write or receive.
Room Resources
Supported room structures and identifiers may be exposed to approved connected systems where applicable.
Rates & Availability
Supported commercial or inventory resources may be accessible according to the integration and granted permissions.
Reservation Resources
Approved booking workflows may use supported reservation data where the interface provides appropriate access.
Webhook Events
Supported events can notify connected applications when event-driven integration functionality is available.
Application Workflows
Approved systems can combine supported resources and events into defined hotel technology workflows.
Authentication
Treat API Credentials as Production Secrets.
Authentication controls which application is making a request and what that application is allowed to access. Credentials should never be treated as ordinary configuration values that can safely be exposed.
✓
Keep secrets server-side
Do not expose private credentials in public browser code or repositories.
✓
Limit permissions
Applications should receive only the access required for the approved workflow.
✓
Separate environments
Where separate test and production credentials are provided, keep them isolated.
✓
Be ready to rotate access
Connected software should support replacing credentials when required.
Application Access
CONTROLLED
01
Identify Application
Define the connected software and its intended use case.
Scope
02
Grant Access
Provide the appropriate interface and permissions where approved.
Access
03
Protect Credentials
Keep secrets inside the intended secure application environment.
Secure
04
Authenticate Requests
Use the method specified for the relevant HotelConnect24 interface.
Verify
05
Review Access
Update or revoke access when the integration changes.
Maintain
Illustrative Webhook Events
Examples
Supported booking event
A connected application may receive a notification when
an applicable booking-related event is exposed.
Supported status event
A workflow may receive notification when an applicable
resource status changes.
Supported integration event
Event-based communication may be available for other
approved system workflows.
Webhooks
React to Events Instead of Repeatedly Asking Whether Something Changed.
Where supported, webhooks can notify a connected application when a relevant event occurs. This can support event-driven workflows without requiring constant repeated requests for the same information.
✓
Configure an endpoint
The receiving application needs an endpoint capable of accepting the event.
✓
Validate incoming events
Do not automatically trust data simply because it reached the endpoint.
✓
Process safely
Event handling should account for repeated or delayed delivery where applicable.
✓
Record failures
Operational teams should be able to identify events that were not processed correctly.
Webhook Lifecycle
Event Delivery Is Only the Beginning.
A production webhook workflow includes validation, processing, failure handling and operational visibility after an event is sent.
01
Event Occurs
A supported event happens inside the relevant workflow.
02
Payload Created
The applicable event data is prepared.
03
Event Delivered
The payload is sent to the configured endpoint.
04
Validate
The receiving application checks the incoming event.
05
Process
The approved application workflow is performed.
06
Monitor
Failures or abnormal behaviour remain visible.
Errors, Retries & Duplicate Safety
Design for the Requests That Do Not Go as Planned.
Production integrations should expect network failures, unavailable services, invalid input and repeated delivery rather than treating every request as guaranteed.
API Security
Connectivity Should Not Create Unnecessary Access.
API and webhook integrations can connect operational hotel systems. Security therefore depends on keeping credentials protected, restricting permissions and validating the information that enters the connected workflow.
✓
Protect secrets
Store credentials in an appropriate secure server-side environment.
✓
Use least-necessary access
Do not request broader permissions than the integration requires.
✓
Validate external input
Treat API and webhook data as structured input that still needs validation.
✓
Remove access when no longer needed
Credentials and integration permissions should be reviewed when systems change.
Security Checklist
INTEGRATION
01
Credentials
Secrets stored outside public client code
CHECK
02
Permissions
Application access limited to the approved use case
CHECK
03
Validation
Incoming data checked before important actions
CHECK
04
Errors
Failures handled without exposing unnecessary information
CHECK
05
Access Review
Credentials can be changed or revoked when required
CHECK
Testing & Production
Test the Workflow — Not Just the Endpoint.
A technically successful request does not prove that an integration is ready for hotel operations.
01
Confirm Access
Verify that the application can access only the resources appropriate to its integration.
02
Test Valid Requests
Confirm that expected request structures produce the intended application result.
03
Test Invalid Requests
Verify how the integration behaves when required data is incomplete or incorrectly formatted.
04
Test Failure Conditions
Plan for timeouts, unavailable services and other situations where the expected response does not arrive.
05
Test Webhook Handling
Confirm validation, duplicate handling and failure behaviour for supported event workflows.
06
Verify Business Result
Confirm that the final hotel workflow matches the intended operational outcome before production use.
Interface Scope
Use the Current Technical Documentation for Your Integration.
Developer functionality can change as HotelConnect24 and its supported integration ecosystem develop.
Important:
Examples on this page are conceptual and do not represent guaranteed
production endpoints, payloads, authentication methods or webhook events.
HotelConnect24 does not promise unrestricted public API access, universal
write access, a permanent sandbox environment or availability of every
hotel resource through every integration. Actual API routes, HTTP methods,
authentication, schemas, permissions, webhook events, delivery behaviour,
limits and production access depend on the interface and integration made
available by HotelConnect24. Developers should build against the current
technical documentation supplied for their approved implementation.
Webhooks & API FAQ
Common Questions About HotelConnect24 Developer Interfaces.
Does HotelConnect24 provide an API?
HotelConnect24 is designed to support developer connectivity through
supported API interfaces. The specific routes, resources, authentication
methods and permissions available depend on the applicable integration.
Is the API open to everyone?
This page does not promise unrestricted public API access. Access can
depend on the integration, approved use case, technical requirements
and applicable HotelConnect24 partnership arrangements.
What API authentication does HotelConnect24 use?
Developers should use the authentication method specified by the
HotelConnect24 interface available to their integration. Authentication
methods should not be assumed from the illustrative examples on this page.
What resources can the API access?
Resource availability depends on the interface and permissions granted
to the integration. Potential workflows may involve supported property,
room, rate, availability, reservation or related platform resources,
but access should only be assumed where it is explicitly provided.
Does HotelConnect24 support webhooks?
Webhook functionality may be available for supported events and approved
workflows. The actual event names, payload structure and delivery behaviour
depend on the current interface documentation.
Are webhook events guaranteed to arrive only once?
Applications should not assume single delivery unless the applicable
technical specification explicitly guarantees that behaviour. Designing
event processing to tolerate repeated delivery can reduce the risk of
unintended duplicate actions.
Should failed API requests be retried automatically?
Not every failed request should automatically be repeated. Retry behaviour
should depend on the error, operation and current interface requirements,
especially where repeated actions could create unintended results.
Does HotelConnect24 provide a sandbox?
A dedicated sandbox or test environment should only be relied upon where
HotelConnect24 explicitly provides one for the applicable interface.
Testing arrangements can differ between integrations.
Can API access update hotel rates or availability?
Read or write access depends on the supported interface and permissions
provided to the specific integration. Developers should not assume that
a resource is writable simply because it is readable.
Can an API integration prevent all booking or inventory errors?
No. Well-designed connectivity can reduce disconnected manual workflows,
but external outages, invalid data, configuration issues, delayed processing
and other operational conditions can still affect connected systems.
Where should I start if I want to integrate with HotelConnect24?
Start with the Developers and Technology Partners pages. Define the
proposed use case first, then confirm whether the required HotelConnect24
interface and permissions are available for that integration.
Build Reliable Connections Around Clear Hotel Workflows.
Use supported HotelConnect24 APIs and webhooks to connect approved applications with relevant hotel data — with controlled access, structured error handling and production testing from the start.