The Certification section helps monitor the technical validation process between the Buyer and Bakuun. This ensures that the API integration meets required standards before going live.
Each row displays one certification request with its real-time progress and execution stats.
Table Reference - Certification Overview
| Field | Description |
| Request ID | Unique ID assigned to each certification process |
| Scenarios | Total number of test scenarios required to complete certification |
| Executed | Number of scenarios already executed. |
| To Execute | Number of remaining scenarios pending execution. |
| Successful | Count of successfully completed test cases. |
| Failure | Count of failed test cases. |
| Status | Displays current status: In Progress, Pending Review, or Certified. |
| Last Update | Timestamp of the last recorded update for that request. |
Note: Clicking on the active certification line redirects to the Certification Details page, which provides a step-by-step breakdown of all executed test cases. This will be explained in the next section.
Use the + Certification button to initiate a new certification request once the current certification has been completed and marked as certified.
Certification → Certification Details
The Certification Details view provides a summary of a specific certification request submitted by a Buyer.
Table Reference - Certification Overview
| Field | Description |
| Certification ID | Unique identifier for the certification request (e.g., CC-RDKXX-X) |
| Account ID | Internal ID of the Buyer |
| Account Name | Name of the partner account |
| Created | Date and time the certification was initiated |
| Last Update | Most recent timestamp of any update or action on the certification |
| Delete Button | Lets you remove the certification request if no longer needed |
Note: Deleting a certification is permanent. Only do this if you are sure the test cycle will no longer proceed.
Certification Progress Summary:
This section gives you a quick snapshot of the current certification progress. The progress bar just below the header displays how many test scenarios were executed, passed, or failed, as well as the type and status of the run.
Table Reference - Certification Details → Certification Progress Summary
| Field | Description |
| Scenarios | Total number of test scenarios included in the certification |
| Executed | Number of scenarios that have been run so far |
| To Execute | Remaining scenarios pending execution |
| Succesful | Number of passed scenarios |
| Failure | Number of failed scenarios |
| Action | Type of run → e.g., Bulk Run if all tests were launched at once. |
| Status | Current progress status (e.g., In Progress, Completed, or Failed). |
Certification → Certification Details → Selection
The Selection tab within the Certification Details page outlines all the functionalities that can be tested and certified for your connection. Each row corresponds to a specific integration scenario (e.g. Mapping and Booking Flows) and displays whether the feature is supported by your system, eligible for certification, or has passed validation.
This tab is organised into multiple subcategories, such as Mapping and Booking → each representing a critical function of the integration. It serves as a reference point for both technical teams and platform reviewers to see what’s implemented, what’s pending, and what’s unsupported.
Certification Details → Selection → Mapping
The Mapping category within the Section tab focuses on verifying your ability to send or receive room mapping data. This is a core requirement for ensuring that your room and rate plans can sync correctly with the Bakuun platform or connected Buyer.
Mapping certification typically involves three methods:
Push – You send mapping data to Bakuun.
Read – You receive mapping information from Bakuun.
Pull – You retrieve mapping data via API on-demand.
Each row represents a testable scenario for one of these methods.
Table Reference - Certification Details → Section → Mapping
| Field | Description |
| Always shown as “Mapping” for this section. |
| Displays the method (Push, Read, Pull) using color-coded tags. |
| Hovering over this icon reveals more technical or functional detail about that specific row. |
| Indicates if the connectivity partners (you) declared this method as supported. |
| Shows whether the method has passed automated certification. |
| If marked Supported = Yes, you can tick the checkbox to include this method in your execution. If No, a 🔺 icon appears and you cannot select it. |
| Don’t forget to click Save after updating this section. | |
Certification Details → Section → Restrictions → Only Push API
This section lists the restriction parameters available in the partner’s API setup. These fields define how inventory, availability, and booking rules are controlled. It also indicates whether each field is Supported, Certified, and Selectable for certification testing.
- Supported: The channel supports this restriction field.
- Certified: The field has been tested and passed during certification.
Select: Field is available for selection in the test scenario for validation.
Table Reference - Certification Details → Section → Restrictions → Only Push API
| Field | Description |
| Lists the different restriction types that can be certified (e.g. Inventory Rate Plan Level, Release, MLOS, etc.). |
| Hover over this icon to get a short explanation of what the restriction is used for. |
| Indicates if the connectivity partners currently support this restriction type in their API setup. “Yes” means it’s technically supported. “No” means it’s not available. |
| Displays the result of the certification test for each restriction. A red 🔺 icon or a “No” tag means the certification failed or was not executed for that capability. |
| This shows whether the restriction type is enabled for certification. A toggle appears if it can be selected. If not available, a red 🔺 icon is shown. |
| Don’t forget to click Save after updating this section. | |
* Full List of Restriction Categories
| Category | Description |
| Inventory Room Level | Indicates if your system supports updating inventory at the room level. |
| MLOS Room Level | Minimum number of nights required to book, applied per room. |
| MLOS Rate Plan Level | Minimum number of nights required to book, applied per rate plan. |
| Max LOS Room Level | Maximum nights allowed per booking, applied per room. |
| Max LOS Rate Plan Level | Maximum nights allowed per booking, applied per rate plan. |
| MLOS Arrival Room Level | Minimum stay required when check-in falls on certain dates, applied per room. |
| MLOS Arrival Rate Plan Level | Minimum stay required when check-in falls on certain dates, applied per rate plan. |
| Max LOS Arrival Room Level | Maximum nights allowed when check-in falls on certain dates, applied per room. |
| Max LOS Arrival Rate Plan Level | Maximum nights allowed when check-in falls on certain dates, applied per rate plan. |
| Close to Arrival Room Level | Blocks check-in on specific dates (e.g., no arrivals on Sundays), per room. |
| Close to Arrival Rate Plan Level | Blocks check-in on specific dates, applied per rate plan. |
| Close to Departure Room Level | Blocks check-out on specific dates (e.g., no departures on Mondays), per room. |
| Close to Departure Rate Plan Level | Blocks check-out on specific dates, applied per rate plan. |
| Stop Sales Room Level | Disables availability completely on selected dates, per room. |
| Stop Sales Rate Plan Level | Disables availability completely on selected dates, per rate plan. |
| Min Advance Booking Room Level | Sets how early a guest can book before check-in date, applied per room. |
| Min Advance Booking Rate Plan Level | Sets how early a guest can book before check-in date, applied per rate plan. |
| Max Advance Booking Room Level | Sets the latest check-in date that can be booked in advance, per room. |
| Max Advance Booking Rate Plan Level | Sets the latest check-in date that can be booked in advance, per rate plan. |
| Sell Threshold | Allows you to restrict how many total rooms can be sold before sales stop. |
| Cancellation Policy and Deposit | Enables setting cancellation rules and deposit terms for the booking. |
Note: A restriction must show Supported: Yes and Certified: Yes to be considered fully integrated and ready for live deployment.
Each of these categories helps define how restrictions and rules are applied to inventory and rate plans. Verifying which are supported and certified is essential for ensuring smooth integration and system behavior consistency across platforms.
Certification Details → Section → Rate Model → Only Push API
This section displays the types of rate models supported by the partner’s connection and whether each has passed certification. These settings determine how pricing is calculated and structured within the platform.
Table Reference - Certification Details → Section → Rate Model → Only Push API
| Field | Description |
| Category | The rate model feature (e.g., extra guest fees, child logic, length of stay). |
| ℹ️ Icon | Hover to view more details about what the specific category does. |
| Supported | Indicates whether the connectivity partners system supports this logic. If marked “No”, it cannot be selected. |
| Certified | Indicates if it has been tested and passed certification. A red 🔺 icon or a “No” tag means the certification failed or was not executed for that capability. |
| Select | This shows whether the rate model type is enabled for certification. A toggle appears if it can be selected. If not available, a red 🔺 icon is shown. |
* Summary of Rate Model Categories
| Field | Description |
| Room Base | Price is set per room, regardless of the number of guests. |
| Occupancy Based | Price varies depending on the number of guests in the room. |
| Length of Stay | Pricing is based on the number of nights stayed, with different rates applied. |
| FPLOS | Fully Pattern Length of Stay – allows rate control based on stay patterns. |
| Hurdles | Minimum rate thresholds must be met before booking is allowed. |
❗ Unsupported or uncertified items are marked with a red triangle icon 🔺 and cannot be toggled.
Certification Details → Section → Addons → Only Push API
This section displays whether the Buyer supports and is certified for handling optional services or extras either before or after the booking is made. These are typically used to offer upgrades or value-added services (e.g., airport transfer, insurance, late check-out).
Table Reference - Certification Details → Section → Rate Model → Only Push API
| Field | Description |
| Category | The rate model feature (e.g., extra guest fees, child logic, length of stay). |
| ℹ️ Icon | Hover to view more details about what the specific category does. |
| Supported | Indicates whether the connectivity partners system supports this logic. If marked “No”, it cannot be selected. |
| Certified | Indicates if it has been tested and passed certification. A red 🔺 icon or a “No” tag means the certification failed or was not executed for that capability. |
| Select | This shows whether the rate model type is enabled for certification. A toggle appears if it can be selected. If not available, a red 🔺 icon is shown. |
* Summary of Addons Categories
| Field | Description |
| Addons pre booking | Indicates if extras can be offered and confirmed before the booking is made. |
| Addons post booking | Indicates if extras can be added after the booking is confirmed. |
❗ Unsupported or uncertified items are marked with a red triangle icon 🔺 and cannot be toggled.
Certification Details → Section → Booking
This section outlines the available booking operations supported by the connectivity partners integration, such as new bookings, modifications, and cancellations. During certification, these operations are tested to ensure full end-to-end compatibility.
Table Reference - Certification Details → Section → Booking
| Field | Description |
| Lists the different booking actions available for certification. |
| Hover your cursor to see a tooltip description of the function. |
| Indicates whether the connectivity partners system supports this logic. If marked “No”, it cannot be selected. |
| Indicates whether this booking action has been successfully tested and certified. A red 🔺 icon or a “No” tag means the certification failed or was not executed for that capability. |
| If the function is supported, it can be selected for testing. Otherwise, a red warning triangle 🔺 is shown.. |
| Don’t forget to click Save Changes after updating this section. | |
Certification → Certification Details → Configuration
This section allows you to manually test property, room, and rate plan combinations along with specific date parameters, to ensure the correct mapping of ARI (Availability, Rates, Inventory) and booking payloads between your system and the platform. Each field is mapped to support data validation prior to full certification.
Table Reference - Certification Details → Configuration
| Field | Description |
| Select the Property ID from the dropdown. This ID is used to retrieve valid Room and Rate Plan combinations for the property. |
| Choose the first Room ID associated with the selected Property. This is used to simulate updates and verify mapping accuracy. |
| Select the first Rate Plan associated with Room ID 1. This is typically used for non-refundable testing. |
| Select the second Rate Plan for Room ID 1. This allows testing of different rate combinations such as refundable vs. non-refundable. |
| Optionally select a second Room ID to validate multi-room mapping and rate combinations. |
| Select the Rate Plan for Room ID 2 if applicable. Useful for advanced testing scenarios. |
| Select a second Rate Plan for Room ID 2 to test additional combinations. |
| Input a test date (YYYY-MM-DD) to perform a one-day ARI update simulation. Use the calendar icon to select the date. |
| Select the first date of a 3-day range for batch update testing. This checks for consistent ARI mapping across multiple dates. |
| Once all fields are filled, click Save Changes to submit and store your selections for ARI testing and validation. |
Configuration details are now set for the selected property and rate plans. You may proceed with execution.
Certification → Certification Details → Execution → Pull API
The Execution tab is where you run the required test scenarios to validate your integration with Bakuun’s platform. This process ensures that all data related to your property, rooms, and rate plans is correctly pushed and pulled through the API.
You’ll see two main tabs under Certification Scenarios:
- Mapping Test Scenario: For verifying configuration and data structure
- Booking Scenario: For validating booking-related operations (explained in the next section)
Certification Details → Execution → Pull API → Mapping Test Scenario
Table Reference - Certification → Certification Details → Execution → Pull API → Mapping Test Scenario
| Field | Description | Status Label |
| Push Property Info | Sends a Push Property Info request to validate that the correct Room and Rate Plan IDs are linked to the Property ID. | Not Yet Run / Success / Failed |
| Fetch Room Details | Pulls the list of rooms based on your Partner ID to confirm all valid rooms are retrievable. | Not Yet Run / Success / Failed |
| Fetch Rate Plan Details | Pulls the list of rate plans based on Room ID to confirm correct mapping of rate plans. | Not Yet Run / Success / Failed |
💡Tip: The test result for each scenario will appear on the right (e.g. Not Yet Run, Passed, or Failed). All scenarios must pass before proceeding to booking tests.
Certification Details → Execution → Pull API → Booking Scenario
This section outlines the key test cases required to validate booking functionality. Each scenario represents a real-world use case that the channel must support to meet certification requirements. All scenarios must be executed and passed via the Extranet interface to complete certification.
Scenarios are grouped into three main types:
- Standard Bookings
- Booking Modifications
- Read and Cancel Functions
The status of each scenario is shown as either:
- ✅ Run: Indicates the test has been completed successfully
- ⚠️ Not Yet Run: Indicates the test has not yet been executed or passed
Table Reference - Booking Scenarios
| Scenario | Purpose | Expected Comment Text
|
| One room, one night | Validates basic booking creation | one-room |
| One room, one night with guaranteed payment card | Validates card inclusion in booking | one-room-with-card |
| One room, one night, two adults | Validates guest count handling | one-room-two-guests |
| One room, one night, 2 adults, 1 child | Includes children in booking payload | one-room-two-adults-one-child |
| One room, one night, 2 adults, 2 children (3 & 7 yrs), 1 infant (1 yr) | Validates mix of adult, children and infant | one-room-two-adults-two-children-one-infant |
| One room, 2 nights with different rates | Confirms rate variation across nights | one-room-different-rates |
| Two rooms, one night | Validates multi-room booking | two-rooms |
| One room, 2 adults with inclusion & extra | Tests inclusion of extras like spa/transfer | one-room-two-guests-spa-included-transfer-excluded |
| Two rooms with inclusion/extra in only one | Confirms selective inclusion across rooms | first-room-one-guest-spa-included-transfer-excluded-second-room-two-guests-no-service |
Table Reference - Modify Reservation Scenarios
| Scenario | Purpose | Expected Comment Text
|
| Modify a reservation | General update to an existing booking | modify-basic |
| Modify stay date | Change only the check-in/check-out date | modify-stay-date |
| Modify number of rooms – Add room | Adds an extra room to the reservation | modify-add-rooms |
| Modify number of rooms – Remove room | Removes a room and consolidates guests | modify-remove-room |
| Modify reservation – Change guest details | Changes name details for the guest | modify-guest |
Table Reference - Cancel and Read Scenarios
| Scenario | Purpose | Expected Comment Text
|
| Cancel reservation | Validates the ability to cancel an existing reservation | (none required) |
| Read Booking – Single | Retrieve status of a single booking by Booking ID | (none required) |
| Read Booking – Bulk | Retrieve list of bookings within a date range | (none required) |
Certification → Certification Details → Execution → Push API
This section shows the real-time progress of the Push API certification. It is used to track test execution across three types of scenarios: Mapping Scenario, ARI Test Scenario, and Booking Scenario. These scenarios help validate the technical connection between the Buyer’s system and Bakuun.
Mapping Scenario → Validates property mapping logic including Room ID, Rate Plan ID, and associations with Partner ID.
ARI Test Scenario → Tests ARI (Availability, Rates, and Inventory) data updates using Push API. Confirms correct data delivery and format.
Booking Scenario → Verifies the ability to send and manage reservations via Push API. Covers full booking flows such as create, modify, cancel, and read.
Table Reference - Certification Scenario → Execution → Push API
| Certification Scenario | Description |
| Mapping | Tests whether the property’s mapping (i.e. Property ID, Room ID, Rate Plan ID) is configured correctly. |
| ARI | Verifies the ability to push and retrieve Availability, Rates, and Inventory data via API. |
| Booking | Simulates the end-to-end flow of creating, modifying, and cancelling bookings to ensure booking messages are sent and received properly. |
Execution → Push API → Execution Example: Mapping Scenario
This scenario sends a Push Property Info request that updates Bakuun with the full list of valid rooms and rate plans associated with the given Property ID. It validates that your system is able to accurately push this data and that Bakuun receives and recognizes all room and rate plan mappings.
Purpose: To confirm your API correctly handles the transmission of essential room and rate plan data, which is required for availability, pricing, and booking requests to function properly.
Sample Test Details:
- Transaction: Displays a real-time API transaction generated by the test.
- Response Validation: The system checks if the response meets the certification requirement (e.g., returns a valid success message).
Status Badge: A green “Successful” badge confirms the test passed.
Table Reference → Execution → Push API → Execution Example: Mapping Scenario
| Element | Description |
| URL | API endpoint your system hits to perform the property info push (e.g. api/updateRates/{PropertyID}/invupdate). |
| Request Payload | Contains credentials and the data payload with all rooms and rate plans. |
| Response Body | Expected to return a success: true flag and message confirming update. |
| Assertions | Must contain at least one success element (e.g. "Success" confirmation). |
✨ Tips
Make sure the Property ID you’re using is correct and mapped properly in your environment.
If your system doesn’t return a success element, review your JSON payload structure.
Use the “Hide Details” or “Show Details” toggle to expand the raw transaction logs for debugging.
You can re-run this scenario multiple times until the status is green.
Execution → Push API → Execution → ARI Test Scenario
This section is designed to validate the supplier system’s ability to send ARI (Availability, Rates, and Inventory) updates via Push API. Scenarios under this tab simulate real-time ARI updates for connected properties.
If your certification setup includes this section, you’ll see one or more enabled scenarios. Each scenario must be manually triggered:
- Click Run beside each enabled test
- The system will display the Request, Response, and Assertions
- A response containing "success": true marks the test as Successful
✨ Note: Scenarios that are not enabled for your account will be greyed out and do not need to be executed.
✅ You must run all enabled scenarios in this section before proceeding to certification enrollment.
Execution → Push API → Execution → Booking Scenario
This section validates how well your system can handle bookings over Push API. It includes test cases for creating, modifying, cancelling, and reading reservations.
Each test scenario must be run individually:
- Click Run to execute the scenario
- Wait for the response and confirmation of success
- Each must show a completed assertion to be counted
✨ Important Requirement: The Enroll Certification button (top right of the screen) remains disabled until:
- All test scenarios assigned to you in this section have been run at least once
Once all test scenarios are triggered successfully, the Enroll Certification button will become available. Clicking this submits your test execution history to Bakuun for review and final validation.
⚠️ Skipping a scenario will prevent enrollment even if other sections are complete.