The Australian Tourism Data Warehouse (ATDW) API exposes structured tourism product data from Australia’s national database. Distributors can use the API to integrate accommodation, tours, attractions, events, food and drink, hire, transport and other experiences into their digital products.
This guide provides a technical orientation for developers. It focuses on concepts rather than code; examples use the ATLAS (ATDW) API format. For detailed endpoint references and sample calls, please refer to the following official documentation:
What the API Provides
Product listings across all tourism categories.
Rich content: names, descriptions, images, videos, prices, availability, facilities, accessibility attributes, contact details and more.
Metadata such as product status, type, classifications and source state tourism organisation.
Search and filtering across keywords, categories, classifications, attributes and geospatial filters.
Real‑time updates via change tracking (delta) and market‑variant translations.
Core API Concepts
Protocol
The ATDW API uses HTTP GET requests over HTTPS. Resources are addressed by endpoint and query parameters rather than REST‑style path segments. Responses are XML by default but can be requested as JSON.
Authentication
All calls require a Distributor API Key. Pass it as a query parameter named key:
Endpoints
Common Endpoints include:
Purpose | Example call |
Search products | GET /api/atlas/products?key=YOUR_KEY&term=whale watching |
Get product details | GET /api/atlas/product?key=YOUR_KEY&productId={PRODUCT_ID} |
Get service details | GET /api/atlas/productservice?key=YOUR_KEY&productId={PRODUCT_ID}&serviceId={SERVICE_ID} |
More like product | GET /api/atlas/mlp?key=YOUR_KEY&productId={PRODUCT_ID} |
Delta updates | GET /api/atlas/products?key=YOUR_KEY&delta=YYYY-MM-DD |
Static data (categories, classifications, attribute types, attributes, states, regions, areas, suburbs) | GET /api/atlas/categories?key=YOUR_KEY etc. |
How Integration Typically Works
Search → Display → Detail Flow
A typical workflow is provided below:
User enters keywords or selects filters
Your site sends a request to /products/search
The Search API returns high-level product fields only (summary data)
User selects a product from the list
Your site calls /products/{id} to retrieve the full product detail
The detail page is rendered using this full dataset
This two-step approach is required because the Search endpoint intentionally returns a lightweight dataset optimised for speed.
This pattern works with any framework (React, WordPress, .NET, etc.).
Data Structure Highlights
Product Objects
A product response can include:
Identifiers: id (product UUID), serviceId, mediaId
Basic information: name, descriptions, product type/category, accreditation
Location: address, geo‑coordinates (lat/long), region/state/area codes
Opening hours and seasonal dates
Pricing information and indicative rates
Facilities, amenities and attributes (including accessibility)
Media: image and video URLs (you decide how to render, optimise or lazy‑load)
Contact/booking URLs and related booking‑platform identifiers
Deals/Offers: Up to three per product/service, each with a name, description, type and in‑market end date)
Fields may be absent if an operator hasn’t supplied that data. Your User Interface (UI) should handle missing prices, accessibility info, social links or media gracefully.
Pagination and Size Limit
Search results are paginated. Use size and page (or pagination tokens) to step through result sets.
The size parameter is capped at 5,000 profiles per call; larger values return a 400 error. Combine size and page to retrieve larger sets.
Filtering
Search parameters include the following:
Search Parameter | Description |
Keyword search (term) | Full‑text across names and descriptions. |
Categories | For example:
|
Classifications | Combine Classifications with Categories (above). For example:
|
Attributes | Attribute codes, for example: ENTITYFACBBQ.
Comma‑separate for AND, pipe for OR. Tags are a special attribute type and can also be filtered. |
Geography | For example:
|
Price & Rating | Indicative rate ranges, star ratings. |
Accessibility Attributes | Our accessibility dataset provides fields such as:
|
Deals & Offers | Filter products that have deals (hasDeals=true) or by deal type. |
Translations
ATDW has integrated machine translation for ten languages.
To request translated content, pass the market‑variant parameter mv with one of the following codes:
CHINESE-S for Chinese Simplified
CHINESE-T for Chinese Traditional
GERMAN
FRENCH
JAPANESE
ITALIAN
KOREAN
SPANISH
INDONESIAN
THAI
Only one language code is allowed per request; untranslated fields fall back to English. Translations are being released progressively, so some content may not yet be available.
Delta Updates
The API may return products with different states such as active, inactive or expired.
To ensure only current, valid tourism experiences appear on your website, distributors must:
Display only active profiles to end users
Remove or suppress products marked as expired or inactive, including those surfaced via delta (UpdatedSince) responses
Content Components
Deals and Offers
While not compulsory, products and services may include up to three deal/offer objects. Each deal has:
A unique ID
A type (e.g. package, discount)
A name and description
An in‑market start and end date (maximum six‑month duration)
The Search API can filter products by the presence of deals.
When displaying deals, please respect the end date by removing expired deals from your channels.
Bookings
The following two booking integration models are supported through the API.
| What is it? | How to use? |
Operator‑supplied URLs | Operators provide booking or shopping URLs.
| The following fields appear in the Get Product response.
Display them as “Book Now” or “Shop Now” links to direct visitors to the operator’s own site. |
Booking platform partnership | Where applicable, booking‑platform identifiers are stored for certain providers. | To offer live inventory/booking, you need a commercial affiliate agreement with the platform.
Use the bookableObjectId or product/service ID to build the deep link to the provider’s booking widget. |
Reviews and Ratings
ATDW does not embed review content. Instead, it stores external system IDs (currently TripAdvisor).
To display reviews:
Establish a content‑API relationship with the provider (TripAdvisor)
Call their API using the external ID
You can search for listings with TripAdvisor IDs via the Search API by filtering on the relevant attribute code - for example, att=ESC_TRIPADVISORID).
Accessibility
ATDW, Destination NSW and Local Government NSW have expanded the accessibility dataset. The new fields provide richer information about accessible facilities and services.
Accessibility fields are available through Get Product and Get Service. Simply filter Search results using the new accessibility attribute codes. For example:
ACCESSIBILITYDISTASSIST
ACCESSIBILITYBOOKING
Integration Best Practices
Cache responses: Cache search and detail responses for 5–30 minutes to reduce call volume. Respect rate limits and size restrictions.
Use pagination: Keep size ≤ 5 000 and iterate through pages for large result sets.
Refresh data regularly: The Distribution Licence Agreement requires that cached ATDW data be refreshed at least twice per week. Use the delta parameter to fetch updates and avoid stale content.
Trigger calls sparingly: Only call the API when users submit a search or request details. Avoid firing calls on every filter change.
Use unique IDs: Always reference products (id), services (serviceId), deals (dealId) and media (mediaId) using the UUIDs returned by the API.
Handle missing fields: Not all operators provide full data. Build resilient UIs that can cope with absent pricing, accessibility or media.
Comply with tracking: Implement ATDW’s tracking methods (web beacons, image URL tracking, contact/booking URL tracking) within 30-days of going live. Append your distributor ID to outbound website and booking links as required.
Stay within rate limits: ATDW enforces call‑per‑minute limits. Review the “API Rate Limiting” guide and back off or cache when approaching the limit.
Honor the Distributor Licence Agreement: Keep content current, do not alter operator‑supplied meaning, and follow attribution requirements. Avoid redistributing ATDW data outside permitted uses.
Typical Integration Steps
Register as a Distributor to obtain your API key. (See: How to Join as a Distributor)
Familiarise yourself with search filters, static data endpoints and translation codes. (See: Integration)
Build a basic search request against /api/atlas/products using filters relevant to your product category.
Design list templates and detail templates that can adapt to missing data.
Implement caching and pagination.
Implement translations and language selectors if needed.
Add booking, deals and review integrations as appropriate.
Implement ATDW tracking pixels and outbound link tagging. (See: Tracking Requirements for Distributors)
Test across multiple product types, regions and languages. (See: Testing your API Integration)
Monitor API usage and adjust caching or call frequency to stay within limits.
Need Support?
Discover how to access Support when and where it's needed.