Partner distribution

Your travel agency front end. Our curated travel infrastructure.

Travel agencies can present selected Qualimundi journeys on their own websites. Qualimundi keeps the content source, assignments, booking handoff, traveller flow, and operational control.

See the flow Compare handoff options
Opportunity Flow Model Handoff Open questions Roadmap
6 live package records ready for assignment
5 destination signals in the current catalog
1:1 one API client, one controlled catalog

Why this fits

A clean split between sales reach and platform control.

The page needs to sell the idea to agencies and make the operating model clear to the client.

For reisbureaus

Show the journeys in your own voice.

  • Use assigned package content
  • Design your own public pages
  • Send interested visitors into a tracked booking path
For Qualimundi

Keep the hard parts centralized.

  • Control which content each partner sees
  • Measure API usage and campaign interest
  • Keep traveller, inquiry, offer, and payment ownership
For owners

More channels without extra admin work.

  • Approved package deals can reach more audiences
  • Owner operations stay in Portal and Buzzard
  • Future reporting can show which channels perform

Partner flow

From assigned content to tracked booking interest.

Short version: the agency displays, the API scopes, Qualimundi fulfils.

01

Reisbureau

Displays content

The agency builds its own public experience with assigned journeys.

02

ApiClient

Controls access

One technical client holds token, scopes, rate limits, and allowed domains.

03

Buzzard

Serves catalog

Only approved package deals assigned to that client are returned.

04

Tracking

Measures intent

API calls, impressions, clicks, and handoffs become visible in Buzzard.

05

Booking

Hands off safely

The traveller enters QM1 or a future themed app for inquiry and payment.

Data model

Reisbureau is the business hub. ApiClient is the technical key.

This distinction matters: it keeps the client-facing partner model clear while letting internal apps and agencies share the same API engine.

Business

Reisbureau

Contacts, domains, onboarding, notes, future theme settings, and dashboard rollups.

Access

ApiClient

Token, scopes, rate limits, tracking key, callbacks, and environment labels.

Catalog

Assignments

Package deals are explicitly assigned per ApiClient, including QM1 itself.

Stats

Dashboard

Usage, content events, handoffs, errors, and future conversion reporting.

Buzzard hub preview

One place to manage the partner.

Planned dashboard
3

Active API clients

18

Assigned journeys

4.2k

Requests this month

126

Tracked handoffs

Booking decision

The content API can start now. Booking handoff stays a choice.

The main decision is not whether distribution can start, but where the traveller journey switches from reseller discovery into platform-owned booking. That choice defines branding, privacy, reporting, and delivery speed.

Option A

QM1 hosted handoff

Fastest validation path. The reseller uses the API for content and discovery, then sends the traveller into the existing QM1 inquiry and payment flow.

How it works
Reuse the current traveller, inquiry, offer, and payment stack with a tracked handoff reference from the reseller page into QM1.
What it changes
This keeps Qualimundi fully in control of booking logic, compliance, support, and conversion handling. It launches fastest, but the brand transition is more visible to the partner and traveller.
Best MVP test
Option B

Themed traveller app

A stronger partner experience where the hosted booking layer still belongs to Qualimundi, but can load reseller branding, styling, and selected copy.

How it works
Add a dedicated handoff layer or themed traveller app that sits in front of the same platform-owned inquiry and payment engine.
What it changes
This gives the reseller a much better white-label feeling without giving away control of traveller data or booking rules. It needs more product design, theming, and frontend work before launch.
Best partner feel
Later

Read-only conversion API

A reporting-focused next step for partners that want more insight after handoff without becoming owners of the booking flow itself.

How it works
Expose tracked handoff outcomes, conversion status, or aggregate performance data through a safe read-only API once attribution rules are stable.
What it changes
This improves partner reporting and trust, but only after privacy boundaries, reference keys, and dashboard expectations are agreed. It supports the commercial model, but does not replace the MVP booking route.
Future phase

Open client decisions

Important questions still to settle before development scope locks.

These are the questions that still need a client answer. Each one changes architecture, admin scope, and rollout speed.

Question 01

Where should booking actually happen after the reseller handoff?

QM1 hosted booking

Fastest MVP

Keep the partner site as the discovery layer, then send the traveller into the existing QM1 inquiry and payment flow.

Route
Reuse the current traveller, inquiry, offer, and payment stack with handoff attribution.
Impact
Lowest build risk and fastest launch, but the white-label feel is weaker.

Branded traveller app

Middle route

Build a hosted traveller flow that still belongs to Qualimundi, but can load reseller branding and theme choices.

Route
Create a dedicated handoff app or themed booking layer on top of the platform-owned flow.
Impact
Stronger partner experience, but more product and frontend work before launch.

Reseller-owned booking API

Future only

Let the reseller own the booking UX and push inquiry or checkout state into Qualimundi through APIs.

Route
Design a full partner booking contract for inquiry creation, status, pricing, and payment coordination.
Impact
Largest architecture change with privacy, payment, and support implications. Not a safe MVP path.
Question 02

How much visibility should a reseller get after the handoff?

Aggregate reporting only

Safest default

Show counts for views, clicks, handoffs, and maybe top-performing journeys without exposing inquiry records.

Route
Keep reporting at the dashboard-summary level inside Buzzard or a future partner dashboard.
Impact
Simplest privacy posture and easiest to approve commercially.

Pseudonymous status updates

Balanced

Allow partners to track status by external reference without exposing traveller identity directly.

Route
Add a read-only conversion/status API keyed by partner references and handoff IDs.
Impact
Better partner trust and reporting, but needs careful data design and privacy review.

Inquiry-level visibility

High risk

Expose detailed traveller or inquiry status to resellers after a handoff.

Route
Build permissions, legal framing, and possibly a dedicated partner panel for inquiry data.
Impact
Heavy compliance and support burden. This can quickly expand beyond the content-API scope.
Question 03

How should tracking and attribution be measured?

API usage only

Lowest effort

Measure only requests, errors, and rate-limit usage per ApiClient.

Route
Use server-side API logs and daily usage tables without requiring partner-side events.
Impact
Easy to ship, but weak as a true view or conversion signal when partners cache content.

Partner event tracking

Better insight

Ask partners to send impression, click, and handoff events from their own front end.

Route
Provide a tracking key, event endpoint, and allowed-domain checks.
Impact
More accurate reporting, but depends on partner implementation discipline.

Hybrid attribution

Best long term

Combine API usage, client-side events, and signed handoff attribution into one reporting model.

Route
Store usage tables, content events, and handoff records under the same ApiClient/Reisbureau structure.
Impact
Best analytics quality, but also the most complete integration to build.
Question 04

How many API clients should one reseller have?

One client per reseller

Simple ops

Give each reseller one token, one scope profile, and one assignment set.

Route
Model the Reisbureau as the main admin hub and keep ApiClient count minimal.
Impact
Easy to manage, but weaker separation between staging, production, and multiple sites.

One per site or environment

Recommended

Split production, staging, and major partner sites into separate technical clients under one Reisbureau.

Route
Keep Reisbureau for business identity, but allow multiple ApiClients with separate limits and assignments.
Impact
Cleaner governance and debugging, with moderate extra admin overhead.

One per campaign or channel

Granular analytics

Create very narrow API clients for campaigns, brands, or special partner channels.

Route
Use the same ApiClient model, but operationally allow many child clients per reseller.
Impact
Strong tracking detail, but much more credential and assignment management.
Question 05

How much branding and theming should the platform support?

Content-only MVP

Fastest path

Let the reseller brand its own website and accept that the platform brand becomes visible at handoff.

Route
Limit theming to partner-side presentation and keep hosted Qualimundi flows mostly unchanged.
Impact
Minimal extra product scope, but not every partner will like the brand switch.

Light hosted theming

Pragmatic middle

Support logo, colors, and localized copy for the hosted handoff layer without building full white-label.

Route
Use Reisbureau theme settings for a limited branded traveller experience.
Impact
Better partner buy-in with manageable complexity if booking stays platform-owned.

Deep white-label

Major product line

Support full partner theming, custom domains, and potentially partner-specific traveller flows.

Route
Turn Reisbureau theming into a formal platform feature with stronger configuration and QA rules.
Impact
High product value for some partners, but also a much broader maintenance commitment.
Question 06

Should partners ever control pricing or markup?

Platform price only

Cleanest MVP

Expose the package as Qualimundi defines it and keep pricing language fixed across channels.

Route
Return only platform-controlled price fields and show the same inquiry/payment basis after handoff.
Impact
Simplest operationally and avoids mismatches between partner copy and booking reality.

Partner framing outside platform

Limited flexibility

Let partners add their own commercial framing on the site, but do not encode markup into platform booking yet.

Route
Keep the API neutral while allowing partner-side merchandising before handoff.
Impact
More commercial freedom, but can create expectation gaps if not carefully managed.

Structured markup support later

Commercial phase

Add platform-aware markup rules or partner-specific pricing later if the commercial model demands it.

Route
Extend assignments, offers, or channel pricing only after booking ownership and reporting are settled.
Impact
Touches pricing, offer, and possibly payout logic. Too much for the first distribution phase.

Rollout

Build the layer in stages, without disturbing booking.

Each step is useful on its own and keeps the complex traveller flow protected.

01

Create Reisbureau + ApiClient

Business settings, contacts, domains, theme placeholders, scopes, and rate limits.

02

Assign package content

Admins select exactly which journeys each API can see. QM1 becomes an internal client too.

03

Expose scoped API

Versioned endpoints return only assigned approved package deals.

04

Track and decide handoff

Measure usage, clicks, handoffs, then choose QM1 or a themed traveller app.

Content examples

The reseller catalog starts with real package deals.

Costa Blanca Spring Breakaway 5 days / 4 nights Algarve Triathlon Reset 4 days / 3 nights Tuscany Gravel and Vineyard Week 4 days / 3 nights

Next conversation

A sellable partner story, backed by an implementable plan.

Use this page to show agencies the opportunity and show the client exactly where Qualimundi keeps control.

Talk to Qualimundi See how QM1 works today