Sign in ☰Pricing and Promotions Overview
Welcome to the Armstrong Collective Partner API. Before exploring our APIs, we recommend starting here to understand how pricing and promotional pricing work, how promotions are applied, and what to expect from each endpoint. This will help ensure your integration is built on the right foundation. For full API documentation including request and response schemas, refer to the API details in the portal.
1. Package Search vs. Live pricing
The API exposes two distinct pricing mechanisms. Understanding when to use each is important for building a reliable integration.
Package search — POST /packages/search
Use this endpoint to discover available packages for a season — for example, to populate a search results page or availability calendar. Pricing is sourced from a regularly refreshed data store and reflects the latest published rates, but is not guaranteed to be bookable at the exact moment of the request.
Treat prices returned from package search as indicative.
Best used for: Search results, itinerary exploration, availability calendars, price comparison across dates.
Live pricing — POST /pricing/live
Use this endpoint to retrieve a real-time confirmed price for a specific package, departure date, service level, and occupancy — for example, before presenting a quote or booking summary to an agent or customer. This endpoint queries the pricing engine directly and returns a price that reflects current availability and any applicable promotions at that exact moment.
Required fields: PackageId, DepartureDate, ServiceLevelId, Currency, Occupancy
Best used for: Pre-booking price confirmation, quote generation, checkout flows.
Note: Always use live pricing before presenting a price to an agent or customer. The price returned may differ from package search if availability or promotions have changed since the search was cached.
Can prices differ between the two endpoints?
Yes. Package search prices come from a cached data store and may not reflect very recent changes. Live pricing queries the pricing engine in real time. Always use live pricing for any price shown to an agent or customer before they confirm a booking.
2. Promotional Pricing
This section explains how promotions are selected and applied across both endpoints, why the API always uses the lowest available price, and what partners should communicate to agents and customers about additional promotions.
How promotions are selected
When multiple promotions are available for a package, both endpoints apply the one that produces the lowest final price. This ensures that pricing can only ever move in your favour.
If multiple promotions are available, the lowest-priced result is always used
If a promotion available at search time is no longer applicable at the time of a live pricing call, the price will not increase — it can only stay the same or decrease
Treat PricePromo as a price floor: once a promotional price has been shown to an agent or customer, a subsequent live pricing call will never return a higher promotional price
Why the lowest available promotion is always applied
The system currently does not support combining multiple promotions in a single API response. Promotion combinability depends on business rules that are verified manually at the time of booking, and not all combinations are valid. To avoid surfacing a price to an agent or customer that cannot be honoured, the API applies the lowest single promotion available as a conservative baseline.
The price returned by the API is a floor, not a ceiling — the final price confirmed at booking may be lower if additional promotions apply
Promotion stacking or combinability is handled by the Reservation Call Centre at the time of booking, based on eligibility
Partners should advise agents or customers that additional promotions may be available and encourage them to confirm final pricing when booking
Agency-specific promotions
Some promotions are specific to individual partner agencies and will only appear in API responses when a valid Agency ID is included in the request. If your integration is not returning expected agency-specific promotions, confirm with your Armstrong Collective contact that your Agency ID is correctly configured.
Note: Pricing reflects the best available rate at time of search. Additional promotions may apply — please confirm with the Reservation Call Centre at time of booking.
3. Other behaviours to be aware of
This section covers specific API behaviours worth knowing before you start building.
Occupancy format
The Occupancy parameter uses a structured string format. Rooms are separated by a semicolon; adults and children within a room are separated by a comma.
Example — two rooms, the first with 2 adults and 1 child, the second with 2 adults - 2,1;2,0
Partial availability — SeatsAvailable: 0
If inventory data is temporarily unavailable, the API may return offers with SeatsAvailable: 0 rather than omitting the offer entirely. Do not treat this as a definitive sold-out signal — always use live pricing to confirm availability before presenting a booking option to an agent or customer.
Promotion data failures are silent
If the system cannot retrieve promotion data for a request, it returns the response without promotions rather than returning an error. Promotions will be an empty array and PricePromo will equal Price (package search) or be absent (live pricing). Do not infer that no promotions exist for a package solely from an empty Promotions array.
Live pricing — partial responses
Live pricing can return a response that includes both pricing data and an ErrorMessage. An ErrorMessage does not necessarily mean the price is unusable — check whether Price is populated. If IsAvailable is false, the package cannot be booked for that configuration.
Season validation
Package search: The Season parameter, if provided, must be a year between 2020 and 2030. Requests outside this range will be rejected. In practice, packages are available up to two seasons ahead, so the effective searchable range is the current year through the next two seasons.
Live pricing: The DepartureDate must be a date in the future. Requests with a past departure date will be rejected.