Question 1

Can I put my own terms and conditions and privacy policy on my white label travel portal?

Accepted Answer

Yes, you can, and you should. A white label portal normally comes with content pages that you control, so you can add your own booking terms, cancellation policy, privacy policy and any licence or registration details you are required to display. Those pages are then linked from the footer and, where the portal is set up that way, from the checkout page as well, so your customer sees your terms before they confirm a booking rather than someone else's. This matters because the booking contract is between you and your customer. Your terms are what govern things like your service fees, how you handle amendments, and how a refund reaches the traveller. They sit on top of the supplier rules, not instead of them, so an airline fare rule or a hotel cancellation deadline still applies exactly as the supplier wrote it. You cannot use your own terms to promise a traveller something the airline or hotel will not honour, so it is worth making clear in your wording that supplier conditions apply to each booking. How much you can edit, and whether you can add extra pages beyond the standard ones, depends on your plan and how the portal has been built for you. Some sections are template driven, and a card payment provider may also insist on particular wording or disclosures appearing before payment. None of this is legal advice either, so the actual wording should be yours or your adviser's. The next step is to list the pages you need to publish and check with us which of them your current setup lets you edit directly.

Question 2

If I cancel a customer's flight, will the API tell me how much refund they are getting and when they will get it?

Accepted Answer

Yes, for most airlines the API can tell you the refund amount before you confirm the cancellation, but nobody can promise the exact day the money reaches your customer. The normal flow is that you ask for a refund quote against the booking, and you get back what the airline will return once its own penalty is taken off, which taxes and fees are refundable, and anything your own portal has added on top. You show that to your customer, and only when they agree do you send the cancellation through. That way there are no surprises later and you have something in writing to refer back to if they query it. Where it gets less tidy is who actually works out the refund. Some airlines answer automatically and the amount is final the moment you cancel. Others accept the cancellation straight away but calculate the refund by hand afterwards, so what you first see is an estimate that can move. Budget carriers often give a credit for future travel instead of money back, and some fares are not refundable at all, in which case only unused taxes may return. Then there is the payment itself. Card payments go back to the same card and the bank adds its own waiting period, while settlement through an account usually shows as a credit rather than cash. Which way each of your airlines behaves depends on the supplier and the fare rules, not on us. Before you cancel anything, pull the refund quote and read the fare rules shown at search time, and ask your account contact which of the airlines on your portal refund automatically, so you can tell your customer honestly whether the amount is final or still an estimate.

Question 3

What happens if the hotel turns out to be full after my customer has already paid on my portal?

Accepted Answer

Yes, this can happen, although it is uncommon. Hotel availability through an API is a live picture of what the supplier is holding at that moment, and that picture can change in the seconds between your customer seeing a room and pressing the pay button. If someone else takes the last room first, or the hotel closes out that rate, the supplier will decline the booking even though the search result looked fine a moment earlier. When that happens the API does not return a confirmation number. Instead it returns a failure or a rejection, and the booking is recorded in your system as unconfirmed rather than confirmed. That is an important difference, because it means you are never left guessing whether a reservation exists. You should treat a booking as real only when you have the supplier confirmation reference back, not when the payment has gone through. What happens to the money depends on how you have set up payment and on the supplier involved. If the card was only authorised and not captured, the authorisation can usually be released. If it was captured, you will normally be refunding the customer or putting the amount towards an alternative hotel. Some suppliers also work on request, which means the booking sits pending until the hotel replies, and in that case you will need to tell your customer that it is not final yet. Your portal can be set up to offer similar hotels straight away so the customer is not left with nothing. It is worth testing a failed booking with your supplier before you go live, and agreeing with your payment provider how authorisations and refunds should be handled.

Question 4

Can I stop my junior staff from seeing my supplier costs and profit in the travel agency software?

Accepted Answer

Yes, in most cases you can. Travel agency software normally works on staff roles, so you decide what each login is allowed to see and do. A role for junior staff can be set to show only the selling price the customer pays, while the net cost from the supplier and the profit on the booking stay visible to you and to anyone else you choose. How far this goes depends on your plan and on how your portal is set up. Usually you can also control who is allowed to change markup settings, who can cancel a booking or process a refund, and who can open the reports that show earnings across the whole agency. Some setups give you one role for all staff, others let you build a separate role for each person, so it is worth asking what level of detail is available before you promise a team member a particular kind of access. One thing to watch is paperwork that arrives from outside the software. Supplier confirmation emails, voucher copies and some documents issued by the airline or hotel can show the amount the supplier charged, and your own system cannot edit those. If your staff forward supplier messages or work from a shared mailbox, they may see cost information even when the screens in the software hide it, so your mailbox access needs the same thought as your logins. Before you hand anything over, create a test login with the role you intend to give your staff, sign in as that user and walk through a search, a booking and the reports to confirm that nothing you want kept private appears on screen.

Question 5

If an airline changes the flight time after I have ticketed, will my flight booking API let me know?

Accepted Answer

Yes in most cases, though how reliably it happens depends on the airline and on the supplier behind that particular booking. Airlines send out schedule change messages after ticketing, and where the supplier passes those messages on to us, we can show the change against the booking in your system so your team sees the new timing rather than hearing about it first from an unhappy passenger. The honest limitation is timing and clarity. Some airlines send a clean, early notice. Others send it late, or send something worded so loosely that a person has to read it and work out what actually moved. Low cost carriers often manage changes inside their own system and email the passenger directly, which means your customer may know before you do. For that reason we suggest treating the API as your main source of truth but not your only one, and keeping an eye on the airline emails that come to your booking address. What you can then do about the change also varies. Accepting the new time, shifting the passenger to another flight the same day, or requesting a refund when the change is significant are all normally available, but some airlines want those actions handled through their own desk or through the supplier rather than straight through the API, so the route is not always the same. Before you go live, it is worth asking which of your airline and supplier sources send post ticketing change messages, confirming whether alerts are part of your plan, and putting a short daily routine in place to review every departure in the next few days.

Question 6

Can I expect hotel search results to come back quickly enough that my customer does not give up waiting?

Accepted Answer

Yes, in most cases hotel results come back fast enough for a customer to stay on the page, but the honest answer is that the speed depends on the suppliers behind the search rather than on the search page itself. When someone searches for a hotel, the request goes out to live supplier systems and waits for them to reply with real rooms and real rates. Some suppliers answer very quickly and some are slower, especially at busy times of day or for dates far ahead, so the overall wait is usually set by the slowest supplier in the group. There are a few things that make a real difference. A search for one city with clear dates and a normal guest count will almost always return faster than a search across a whole region or country, because the supplier has less to look through. Hotel names, photos and descriptions are generally held ready in advance, so what you are really waiting for is the pricing and availability. Where more than one supplier is connected, results can be shown as they arrive instead of holding everything back until the last one replies, which makes the page feel quicker even when the full set takes a moment longer. What we cannot promise is a fixed response time, because we do not control how fast a supplier replies and the number of suppliers on your account affects the picture too. If one supplier is consistently slow, that can usually be handled by limiting how long the search waits for it or by reviewing which suppliers are switched on for which destinations. Run a few test searches on the destinations and dates you sell most, note anything that feels slow, and send us those examples so we can look at which supplier is holding the results up.

Question 7

Can I send a customer a quote with two or three options before they decide to book anything?

Accepted Answer

Yes, you can usually build a quote with a few different options and send it to your customer before anything is confirmed. The normal way it works is that you run a search in the software, save the flights, hotels or packages you like the look of, add your own markup or a note about what is included, and then send the whole thing out as a single quote the customer can read and compare. What the customer receives depends on how your portal is set up. Some agencies send a simple document by email with the options listed one after another, and others prefer a link that opens a page carrying their own logo and colours, where the customer can look through the choices and tell you which one they want. Whether the customer can click straight through from the quote to pay, or whether they have to come back to you to confirm, depends on your plan and on how you have chosen to collect money. The honest limit is that a quote is not a reservation. Prices and availability come from the supplier in real time, so a fare or a room rate that was live when you built the quote can move or disappear before the customer makes up their mind, especially over a weekend or during a busy season. Good practice is to put a validity note on every quote and to re-check the price at the moment of booking rather than assuming it has held. If quoting is a big part of how you sell, it is worth asking us to walk through the quote screen with you first, so you can see exactly what your customers will receive and how long you want your quotes to stay valid.

Question 8

Do I need my own contracts with hotels to use your hotel booking API, or do you supply the hotels?

Accepted Answer

No, you do not need your own hotel contracts to start selling through a hotel booking API. The usual arrangement is that the connection arrives with hotel inventory already attached, so you can search, quote and book from the first day without speaking to a single property yourself. For most agencies this is the main reason to use an API at all, because negotiating with hotels one by one is slow work and only really pays off in places where you have a strong local presence. That said, some suppliers sitting behind that inventory do ask you to hold your own agreement or credentials with them. Where that applies, we connect the API to your account rather than supplying the rooms ourselves, and the commercial terms, including how you are billed and how your commission is paid, stay between you and that supplier. Which ones work this way depends on the markets you sell into and the plan you take, so please ask rather than assuming everything is covered. If you already have direct deals with hotels in your own city or region, those can normally be loaded alongside the API inventory so your customers see both in one set of results. How much control you get over those rates, and whether your team can update availability without help, depends on the setup you choose. The simplest next step is to send us the destinations you sell most often, and we will tell you plainly which hotels would come with the connection and which would need an agreement in your own name.

Question 9

Can two of my staff work on the same booking at the same time without overwriting each other?

Accepted Answer

Usually yes, but it depends on what each person is doing. Most travel agency software lets several people be logged in at once and work on different parts of the business without any trouble. Two staff members viewing the same booking at the same time is perfectly normal. The care is needed when both try to edit the same record in the same moment, because the last change saved can replace the earlier one. Many systems reduce that risk by locking a booking while someone has it open for editing, so the second person sees a message saying it is already in use and who has it. Others allow both to edit and simply record each change in the booking history, so you can see what was altered and by whom. Which behaviour you get depends on the software you are using and sometimes on your plan, so it is worth asking directly rather than assuming one or the other. Actions that go out to a supplier, such as a cancellation or a date change, are a separate matter. Those are sent through the supplier system, and once one person has sent the request the second person cannot send it again. In that situation your staff member will normally get an error back from the supplier rather than a duplicate change, but the wording of that message is not always clear, which is why a quick refresh of the booking before acting saves confusion. The practical answer is to give each staff member their own login rather than sharing one, so the record of who did what is accurate, and to agree internally on who owns a booking while it is being worked on. Ask us to confirm how editing and locking behave in your setup, and check whether your booking history shows the staff name against each change.

Question 10

Will my customers ever end up dealing with you instead of me if something goes wrong with a booking on my portal?

Accepted Answer

No, in normal use your customers deal with you and only you. A white label travel portal is presented as your own travel business, so your name, your logo and your contact details are what appear on the site, on confirmations and on vouchers. Our role sits behind that, supporting you as the agency rather than the traveller, and we do not approach your customers or market to them. There is one honest exception worth knowing about. When a booking is made, the airline or hotel usually holds the passenger or guest contact details you entered, and suppliers sometimes write to travellers directly about things like a schedule change, a check in reminder or a disruption. That is the supplier's own communication and it is outside anyone's control, including ours. Many agencies handle this by entering their own agency contact details where the supplier rules allow it, so messages come to the office first, though some suppliers insist on genuine traveller details. For anything that needs a change or a refund, the path is normally that your customer contacts you, you raise it with us or with the supplier, and you go back to your customer with the outcome. How quickly that can be dealt with, and whether any help is available outside normal office hours, depends on your plan and on the supplier involved, so it is worth confirming rather than assuming. Before you go live, decide which contact details you want shown on the portal and used in bookings, and agree internally who answers traveller queries so nothing sits waiting.