PMS and Complex System Certification for Inlet API Integrations
This article extends the standard Inlet API certification process for PMS integrations and other complex booking systems.
Partners should first review the Inlet API Certification Process. This article describes the additional scenarios that may need to be certified when the integration supports PMS workflows, multi-room bookings, room changes, group bookings, common-door access, guest communication rules, or other advanced user journeys.
The certification verifies that the integration can reliably create, update, re-sync, and revoke access based on real booking changes in the source system. It is intended for PMS providers and integration partners, not lock installers or locksmiths.
The purpose is simple:
The correct person must receive access to the correct room, door, or resource, for the correct time period — and that access must be updated, re-synced, or removed when the booking or access conditions change.
1. When is PMS or complex certification required?
PMS or complex certification is required when an integration supports more than simple one-room bookings.
Examples include:
- Hotel PMS integrations
- Company bookings
- Booking company, agency, or tour operator bookings
- Group bookings
- Multi-room bookings
- Room changes
- Check-in and check-out status updates
- Common-door access
- Meeting rooms, conference rooms, or other bookable resources
- Booking types where guest communication should be suppressed
The certification scope depends on what the integration supports. A partner may be certified for standard PMS bookings without being certified for every advanced use case.
Only scenarios that have been tested and approved are included in the certified scope.
2. Core requirements
Before PMS or complex certification, the integration must meet Inlet’s general API requirements.
| Area | Requirement |
|---|---|
| Booking timing | Bookings should not be sent to Inlet more than 72 hours before arrival, unless otherwise agreed. |
| Required data | Required fields such as partner name and internal booking ID must be included. |
| Stable booking ID | The integration must use a stable booking reference so updates and cancellations can be linked to the original booking. |
| Inlet reference | The integration must store the reference returned by Inlet, where applicable. |
| Access information | Returned access codes, links, and other relevant access information must be stored where needed for guest communication, backup delivery, updates, and troubleshooting. |
| Contact details | Email addresses and phone numbers must be validated before being sent to Inlet. Phone numbers must include country code. |
| API responses | The integration must read and act on API response messages, not only HTTP status codes. |
| Error handling | API errors and response messages must be handled by the integration. |
| Retry logic | Temporary errors must be retried automatically, with a defined retry limit. |
| Logging | The partner must be able to troubleshoot booking events from their own logs. |
| Re-sync handling | The integration must be able to re-sync affected bookings when requested by Inlet, for example by sending an UpdateAccess request and storing any newly returned access code or link. |
3. Certification scenarios
Only scenarios supported by the integration need to be certified. Any scenario that has not been tested is not included in the certified scope.
3.1 Standard booking
Create a standard booking with guest name, arrival date, departure date, room, email address, and phone number.
Expected result:
- Access is created for the correct room.
- SMS and/or email is sent according to the configured rules.
- Access works only during the valid booking period.
- The returned reference and access information are stored where required.
3.2 Company booking
Create a booking where the customer or payer is a company, but one or more named guests are assigned to rooms.
Expected result:
- Access is created for the correct guest and room.
- Communication is sent to the named guest if guest contact details are available and communication is enabled.
- The company profile does not prevent the guest from receiving the correct access.
3.3 Booking company, agency, or tour operator booking
Create a booking from a booking company, agency, tour operator, or similar third party.
Expected result:
- Access is created for the correct room, door, or resource.
- The code or access link is made available through the agreed method, such as booking notes, API response, or another approved channel.
- SMS and email are not sent directly to the guest if communication should be suppressed for this booking type.
This is typically used when the hotel, company, or group organizer distributes access information themselves.
3.4 Booking update
Update a booking before arrival.
Examples include:
- Date changes
- Guest detail changes
- Phone number or email changes
- Room changes
Expected result:
- Inlet receives the update.
- Existing access is updated instead of creating incorrect duplicates.
- The final access matches the latest booking data.
- The partner system stores any updated access information returned by Inlet.
3.5 Re-sync and bulk access update
The integration must be able to re-sync affected bookings when Inlet requests it.
This may be required if access information needs to be regenerated, for example after a lock replacement, lock algorithm change, failed algo-lock, or other operational change affecting already generated access codes.
Expected result:
- The partner can identify affected bookings.
- The partner can send an
UpdateAccessrequest for affected bookings. - Inlet generates and returns new access information where applicable.
- The partner system stores the newly returned access code or link.
- The guest-facing access information is updated so the old code or link is not used.
This flow is important because access codes generated for one lock algorithm may not work if the lock is replaced or changed to a different algorithm.
3.6 Check-in and check-out
If the integration supports PMS status updates, check-in and check-out behavior must be tested.
Expected result:
- Access is activated according to the agreed check-in rule.
- Access expires or is revoked according to the agreed check-out rule.
- The integration clearly defines whether expiry is based on booking end time, check-out time, PMS status, or another agreed rule.
If the integration does not use PMS check-in/check-out status, this must be documented.
3.7 Room change
Change the room on an existing booking.
Expected result:
- Access is removed from the previous room.
- Access is created or updated for the new room.
- The guest does not keep access to the old room.
- Any updated access code, link, or reference information is stored correctly.
Room changes should be tested both before arrival and after check-in if the integration supports both.
3.8 Cancellation and no-show
Cancel a booking, delete a booking, or mark it as no-show.
Expected result:
- Active or future access is revoked.
- Previously sent access no longer works.
- The cancellation event is logged and traceable.
The partner must document which PMS statuses revoke access.
3.9 Early check-in and late check-out
If the PMS supports changing arrival or departure times, the integration must update the access period accordingly.
Expected result:
- Access is extended, shortened, or activated earlier when supported.
- If the PMS cannot support this, the limitation is documented.
- The actual behavior matches the documented behavior.
A limitation is acceptable, but it must be known before production use.
4. Advanced scenarios
The following scenarios are required only when supported by the integration.
4.1 Group bookings and multi-room bookings
Create a booking with multiple rooms or multiple guests under the same reservation, company, group, or organizer.
Expected result:
- Access is created for each relevant room.
- Codes or links are not mixed between rooms.
- Communication follows the agreed setup.
- The partner system can identify which guest, room, or booking each access belongs to.
The partner must document whether access is created per guest, per room, per booking, or per group.
4.2 Advance code generation for groups
Some group bookings require access information to be prepared before arrival so a company, travel organizer, or group leader can distribute it.
Expected result:
- Access is generated within the agreed pre-arrival window.
- Access information is available through the agreed method.
- The integration respects Inlet’s booking timing rules unless otherwise agreed.
- Any special timing agreement is documented as part of the certified scope.
4.3 Common-door access
If the integration supports shared access areas, common-door access must be tested.
Examples include:
- Main entrance
- Night entrance
- Floor or corridor doors
- Parking
- Gym
- Conference areas
Expected result:
- The guest receives access to the correct room and relevant shared doors.
- Common-door access is valid for the correct period.
- Common-door access is removed when the booking expires or is cancelled.
Known limitations, such as lock-system code capacity, must be documented as part of the certified scope.
4.4 Meeting rooms and other resources
Some systems support bookable resources that are not hotel rooms, such as meeting rooms, conference rooms, event spaces, or activity rooms.
Expected result:
- The PMS resource is mapped to the correct Inlet access point.
- Access is valid only for the booked time.
- Updates, cancellations, and resource changes are handled correctly.
5. Communication requirements
The integration must control when Inlet should send communication and when communication should be suppressed.
| Booking type | Typical behavior |
|---|---|
| Private booking | SMS and/or email is sent to the guest. |
| Company booking | SMS and/or email is sent to the named guest if contact details are available. |
| Booking company / agency | Access may be generated without direct SMS or email to the guest. |
| Group booking | Access may be sent to guests, sent to an organizer, or stored in the PMS, depending on setup. |
The integration must also handle missing or invalid contact details. Failed communication should be visible in logs and possible to troubleshoot.
If communication is suppressed, the partner system must still make access information available through the agreed method, such as the API response, booking notes, PMS field, or another approved channel.
6. Error handling and retries
The integration must handle temporary failures safely.
This includes:
- API timeouts
- Temporary API errors
- Invalid booking data
- Failed updates
- Failed cancellations or revocations
- Failed re-sync or bulk update events
Expected behavior:
- Temporary errors are retried automatically.
- Retries have a defined limit.
- Failed events are logged.
- The partner can identify which booking failed and why.
- Failed revocations are treated as important, since old access may remain active until resolved.
- Failed re-sync or bulk update events are treated as important, since guests may otherwise keep old or invalid access information.
7. Certification result
After testing, Inlet will confirm which scenarios are certified.
Certification may be approved for a limited scope, for example:
- Standard hotel bookings
- Company bookings
- Booking company bookings without guest communication
- Group bookings
- Multi-room bookings
- Room changes
- Check-in and check-out status updates
- Common-door access
- Meeting rooms or non-room resources
- Re-syncing or bulk-updating existing access
Features that have not been tested are not included in the certified scope.
Re-certification may be required if the integration changes significantly, such as changes to booking logic, communication rules, room-change handling, common-door logic, group bookings, re-sync handling, or error handling.
Certification meeting checklist
This checklist can be used during the certification meeting.