triangle-exclamation
The URL of the API test environment changes on February 4th.
Check all details of the change.arrow-up-right
search
Join nowLoginHelp

Maximising availability using Multi-sourcing

hashtag
1. Introduction

If you're integrating the Tiqets API and wondering how to support multiple suppliers for the same experience, you're in the right place. When availability is tight, customers can hit dead ends—and that’s missed revenue for you. Multi-sourcing takes care of that by intelligently merging identical products from different suppliers into one product.

The best part? You don’t need to add any complex logic. Just follow the usual flow, and we’ll handle the complexity behind the scenes.

Here’s what you gain with multi-sourcing:

✅ Maximize Availability – One listing that reflects supply from all sources.

✅ Increase Sales – More bookable options reduce drop-offs.

✅ Reduce Manual Work – No more juggling or replacing sold-out links.

✅ Improve UX – Your users enjoy a cleaner, more reliable booking journey.

hashtag
2. Detecting a Multi-source Product

When you call /products/{product_id}, take a moment to check if the product includes a product_groups field with type: booking_sources. This is your indicator that the product is part of a multi-source setup. In this case, we strongly recommend switching to the multi-source product instead of continuing with any of the individual items in the group.

The key detail here is the group_id. That’s the product ID you’ll want to use moving forward—whether you’re checking availability or placing a booking. Think of it as your unified version of the product, where all supplier options come together in one place to simplify your integration.

Here’s what it looks like:

"product_groups": [
  {
    "group_id": "1109706",
    "type": "booking_sources",
    "products": [
      {
        "id": "1093736",
        "title": "Warner Bros. Studio Tour: From Kings Cross",
        "currency": "EUR",
        "from_price": 121.14
      },
      {
        "id": "1098056",
        "title": "Warner Bros. Studio Tour: From Russel Square",
        "currency": "EUR",
        "from_price": 148.51
      },
      {
        "id": "1109706",
        "title": "Warner Bros. Studio Tour: From London Victoria",
        "currency": "EUR",
        "from_price": 106.59
      }
    ]
  }
]

📝 Let’s say you initially retrieved product_id = 1098056. When you check the product details and see that it belongs to a group with group_id = 1109706, that’s your signal to switch. From that point on, you should use product_id = 1109706 in all your API calls—whether you’re checking availability or placing a booking.

That group_id is essentially your multi-source product ID. It’s the one that consolidates availability across all the suppliers, making your integration cleaner and more resilient.

👉 The products array is just for reference. If you want to show the different supplier options to your users, you can—but it's completely optional.

hashtag
3. Getting Availability

You don’t need to change anything in your availability logic. Simply call /products/{product_id}/availability as you normally do. We’ve already taken care of merging the inventory from all sources behind the scenes.

Here’s what you can expect:

  • ✅ The response format stays exactly the same as you're used to.

  • ✅ You’ll receive a unified list of all available variants.

  • ❌ No additional filtering or logic is needed on your end.

hashtag
4. Booking Flow: No Change Required

Booking is just as easy. Use the same product ID and variant ID you got from the availability call. That’s it.

Behind the scenes, we’ll pick the best booking source—We always look for the one with the lowest price to help customers get the best deal possible and convert. You don’t need to do anything.

Once booked you will receive the commission of the booked product.

hashtag
5. Important: Use /orders/{order_reference_id}/tickets for Post-Booking Info

After a booking is confirmed, always call the /orders/{order_reference_id}/tickets endpoint. This is where you’ll get all the information your customer needs for their visit:

  • 📍 Instructions (like where to go and when to be there)

  • 📌 Meeting points (often supplier-specific)

  • ℹ️ Any details tied to the exact booking source

This step is especially critical for multi-sourced products. Since each supplier may have different logistics (e.g., different departure locations or check-in procedures), skipping this step could leave your customer confused.

Here’s a sample response from /orders/{order_reference_id}/tickets:

🎯 Best practice: Always include this step in your post-booking flow so your users are fully informed—and always make sure to share the meeting point and instructions with your customers to avoid confusion and ensure a smooth experience.

hashtag
6. Best Practices

Here are a few friendly reminders:

  • ✅ Use /orders/{order_reference_id}/tickets to finalize the customer experience.

  • ✅ Treat multi-source like a normal product.

hashtag
Edge Cases & FAQ

Q: Can a variant come from multiple suppliers? Yes, that’s actually the essence of multi-sourcing. We’ve designed the system to handle this on your behalf, so you don’t have to worry about where a particular variant is coming from.

Q: Can I choose which supplier gets the booking? No, that part is handled automatically. We’ll always select the best available supplier, typically the one offering the most competitive price, so your customers get the best value without you needing to configure anything.

Q: What if one supplier runs out of availability? You don’t need to do a thing. If one source is out, we’ll serve availability from another one in the group—automatically.

Q: Do I need to poll for availability more often? No. You can treat multi-source products the same way as any other product in your system. The availability endpoint gives you the latest view already, with all the sources combined.

PreviousHow to implement language selectionNextHow to implement Cross & Upselling using Product Groups

Last updated

Was this helpful?