# RFP Workflow

## Overview

This guide explains how demand-side partners (for example Travel Management Companies, Meetings & Events platforms, marketplaces, and booking engines) can integrate with the **MeetingPackage Distribution API** to submit **Requests for Proposal (RFPs)** and track their lifecycle.

The RFP workflow is designed for scenarios where:

* real-time availability is not required or not supported
* venue review is needed before confirmation
* pricing or requirements are complex or bespoke


In contrast to Direct booking, the RFP workflow does **not** perform API-level availability checks. Instead, venues review requests and respond with proposals through the MeetingPackage platform.

## What is an RFP in MeetingPackage?

In the RFP workflow, partners submit a structured request describing an event or group booking requirement. MeetingPackage then:

1. Distributes the request to one or more targeted venues
2. Creates a **venue-specific order** for each venue
3. Invites venues to respond with proposals
4. Tracks proposal and booking status changes


Each RFP creates a **group request**, containing one **order** (venue-specific lifecycle object) per targeted venue. An order may result in a confirmed booking, but not all orders do.

## Communication models

MeetingPackage supports two levels of RFP integration. The appropriate model is agreed during onboarding.

### 1. One-way RFP (submission only)

* Partner submits RFP data
* No booking or proposal retrieval via API
* No event (webhook) integration
* Suitable for partners that only need to forward RFPs to venues


### 2. Two-way RFP (submission + lifecycle visibility)

* Partner submits RFP data
* Partner retrieves outcomes and status using API operations
* Optional event (webhook) notifications for updates
* Suitable for platforms that display proposals or booking status to users


## High-level lifecycle

`RFP submitted` → `Venue proposals` → `Proposal accepted` → `Booking confirmed`

- Each step is tracked per venue using a stable identifier.


## Key identifiers

When working with RFPs, the following identifiers are important:

* **RFP / group ID** – identifies the overall RFP request
* **Order ID** – identifies the venue-specific lifecycle object (may also be called *Booking ID*)
* **Venue ID** – identifies the venue targeted by the RFP


Order IDs (Booking IDs) are used consistently across:

* API responses
* event notifications
* booking retrieval operations


## Workflow steps

### Step 1: (Optional) Retrieve venue configuration

Before submitting an RFP, you may wish to retrieve the list of venues available to your partner account, along with configuration data such as booking types and market segments.

Use **Get venue configurations** to retrieve:

* venue identifiers
* booking type IDs
* market segment IDs


This data may be cached and refreshed periodically.

→ See [Get venue configurations](/openapi/distro-openapi#tag/Configuration) in the API Reference.

### Step 2: Submit an RFP

Submit the RFP as a structured JSON payload, including:

* the list of targeted venues
* event details and requirements
* optional customer and account information


On success, MeetingPackage returns:

* a group-level RFP identifier
* one `order ID` per targeted venue


These identifiers should be stored for later correlation.

After submission:

* MeetingPackage normalises the RFP data
* the request is distributed to venues
* venues review and respond through the MeetingPackage platform


→ See [Send RFP (lead data)](/openapi/distro-openapi#tag/Rfp) in the API Reference.

### Step 3: Track updates via events (optional)

Partners may register an HTTPS endpoint to receive **event notifications** when relevant changes occur, such as:

* proposal creation or updates
* booking confirmation or cancellation
* venue visibility changes


Events notify you that **something has changed**. They do not include full booking details.

After receiving an event, you should call the API to retrieve the current state.

→ See [Events](/docs/guide/events) for details.

### Step 4: Retrieve booking and proposal details

Depending on your use case, you may retrieve details using one or more of the following operations:

* **Get booking details** – retrieve details for a specific order/booking
* **Get RFP group orders** – retrieve all orders for a given RFP
* **Search bookings** – locate bookings using customer details (for support or reconciliation)


These operations are typically used after receiving an event notification, but may also be called directly.

→ See the [Bookings](/openapi/distro-openapi#tag/Bookings) and [RFP](/openapi/distro-openapi#tag/Rfp) sections in the API Reference.

## Events and follow-up

Events indicate that a change has occurred. To retrieve details:

1. Receive an event notification containing an `order_id`
2. Call the appropriate GET operation
3. Update your internal state or UI


Partners may also receive events when venue visibility changes and should update their cached configuration accordingly.

## What’s out of scope

The following aspects are intentionally out of scope:

* proposal negotiation details
* messaging between partners and venues
* detailed pricing breakdowns
* direct booking workflows


## Support and onboarding

MeetingPackage provides assisted onboarding for RFP integrations, including:

* schema mapping and validation
* test submissions
* operational support during rollout


For help, contact your MeetingPackage Partnerships or Technical contact, or email
[integrations@meetingpackage.com](mailto:integrations@meetingpackage.com).