RateDock Account Migration Steps

account migration from ratedock to b aggregrate due date 2025 28 02 status ongoing | enhancement | general overview if your account is migrating from ratedock (previously accessed via dashboard ratedock com), no major platform or integration redesign is required that said, minor configuration updates and validation may be necessary , particularly for integrations that rely on static or deprecated mappings (such as numeric meal plan codes) or that assume a single acknowledgement per booking for multi room reservations 👉 you can only get started after receiving the email containing your new account password reset link 👉 if ip whitelisting is required, please note that our new ip addresses are 13 251 118 21 and 13 251 118 32 access and activate your account step 1 > login to your new account when accounts are being migrated in batches all migrations are expected to be completed by 10 february 2026 you will receive an email notification once your account has been migrated until then, your account will be temporarily inaccessible where login using the new account portal https //accounts bakuun com how 👤 username same as your existing ratedock username 🔒 password a password reset link will be sent to your registered email address important to know your customer id (rdkxxxx) remains unchanged from the old platform step 2 > access to b aggregate where after logging in, navigate to store how click anywhere within the b aggregate section a new window will automatically open step 3 > accept terms & conditions where after logging in, navigate to store, click anywhere within the b aggregate section how you will be prompted to review and accept the terms & conditions step 4 > booking api endpoint & credential update as part of this migration, you are required to update the booking api endpoint and access credentials , which will be used going forward where b aggregate → production → webhook → booking → push booking endpoint production → api keys → booking → secret key access credential (secret key) when you may update the endpoint at any time before 28 february 2026 important to know routing between the old and new platforms is already in place 👉 there will be no service disruption during the transition step 5 >mapping api endpoint & credential update this section applies only if you are using get property read properties where b aggregate → production → webhook → mapping → read mapping endpoint production → api keys → booking → read key access credential (read key) when the update can be completed at any time however, it must be completed to continue retrieving property mapping data detailed enhancements & new features ⚠️ action required if you previously used numeric meal plan codes features applies to what’s new what you need to do meal plan code updated mapping / booking implemented standardized meal plan code handling to ensure consistent meal plan mapping across all integrations added support for the all inclusive meal plan code updated meal plan codes room only → ro breakfast → bb half board → hb full board → fb new meal plan code all inclusive → ai 👉 mandatory action • update your meal plan mapping logic to use the new string based values • remove any dependency on numeric values (0–3) • ensure your booking, mapping, and downstream systems accept string codes previous mapping (deprecated) 0 = ro 1 = bb 2 = hb 3 = fb tracking id mapping / ari / booking added tracking id to all api responses for improved debugging and traceability no mandatory changes required • recommended log and persist the tracking id in your system • always reference the tracking id when contacting support data erase ari push api only added erase ari functionality going forward, any field sent with the value “n/a” must be interpreted as an explicit instruction to delete/clear that data expected behavior on partner side when receiving a field with value “n/a” , the corresponding value must be erased the deletion must apply to the full date range specified in the request no partial retention of previous values should remain for the affected range this mechanism allows us to remove data at any supported level (rate, inventory, restriction, etc ) without requiring separate delete endpoints booking confirmation – room index booking / acknowledgement booking confirmations are now returned per room index for multi room bookings the booking flow itself is not affected 👉 to review no action required for single room bookings for multi room bookings (e g 2 rooms or more) the acknowledgement response will contain one entry per room index update your logic to iterate through all room indexes in the acknowledgement do not assume a 1 1 relationship between booking id and acknowledgement entry (1 booking → n room acknowledgements) ensure each room acknowledgement is processed, stored, or reconciled according to your internal flow important note on property data all properties are already available on the new platform this update ensures continued synchronization as we fully transition to the new infrastructure support & assistance if you need assistance at any stage, you can reach us through the following channels email mailto\ support\@bakuun com slack join our slack community hub https //join slack com/t/bakuuncommunity/shared invite/zt 3jjps64no lnwfwzhyidb wi9nxyjqig chat https //wa me/6589516173 , https //line me/r/ti/p/%40900esswi , https //m me/618169861534697 ⚠️ important notes support is available only for registered clients with an active product when contacting support, please provide your product id , which can be found in the settings page (top right section) of your account technical support hours monday to friday, 9 00 am – 11 00 pm (gmt +8)