204 Error - No results found

This comprehensive guide covers how to troubleshoot and resolve 204 'no results found' errors in your integrations, with dedicated sections for both Buyers and Sellers.

Terminology: In this article, 204 error, no results, and no availability refer to the same condition: the Seller returns zero results for a request.

When to Use This Article

You received a 204 error in your Search, Quote, or Book response and need to troubleshoot the issue. If you're trying to prevent high no-availability rates before they occur, see How to Optimize Search Results.

What Does a 204 Error Mean?

A 204 error occurs when a Seller does not return any results for the specific search criteria in the Buyer's request (e.g., hotel, dates, market, etc.).

Example:

"errors": [
            {
              "code": "",
              "description": "No results found",
              "type": "204"
            }
          ]

This error is primarily returned in Search responses, but it can also appear in Quote or Book responses if an additional search is required for the method.

As a Buyer, you can audit the Seller's response by setting auditTransactions to true in your Search request.

info

For more details on auditing Seller transactions, see Audit Search Logs Functionality.

For Buyers

How to Handle 204 Errors in Search Responses

This section is an incident runbook for active 204 failures. It is designed for fast root-cause isolation and recovery on specific failing searches.

For long-term availability improvement planning, use How to Optimize Search Results.

Start with Buyer credentials before reviewing portfolio, mapping, or cache behavior. If credentials are not active or not aligned, the rest of the checks are not reliable.

Priority	What to Review	Source of Data	What Good Looks Like	Action if Fails
1	Buyer credentials and access setup	HotelX Credentials, My Connections details	Active credentials and access configuration aligned with Seller setup	Fix credentials or access configuration first
2	Seller raw response vs Travelgate response	Audit Search Logs Functionality, audit transactions	Seller response and Travelgate output are consistent for tested criteria	Identify where availability is being filtered
3	Portfolio and mapping coverage	Connections Content, HotelX Mapping File Overview	Requested hotels are enabled and mapped correctly	Force update content and remap valid hotels
4	Request constraints (market, dates, stay)	Seller Metadata and test searches	Search criteria match Seller restrictions	Adjust request parameters to valid values
5	Speed/cache behavior	Speed Mode Settings	Standard mode used for troubleshooting baseline	Switch from Fast to Standard and re-test
6	Seller validation with evidence	Audit logs, request/response samples, credential context	Seller confirms credentials, portfolio scope, and criteria compatibility	Align Seller-side configuration or request rules
7	Support escalation package	Request/response logs, audit evidence, successful Seller references	Support receives complete reproducible case details	Open support case with full evidence package

1. Verify Buyer Credentials First

• Confirm your Buyer credentials are active and correctly configured in your connection.
• For Legacy Pull Buyers API, ensure request configuration matches My Connections.
• If credentials are incorrect, stop and fix this first.

2. Audit the Seller Response

Auditing lets you inspect the Seller response in its original format before Travelgate processing.

• For HotelX API users: Set auditTransactions: true in your Search request.
• For Legacy API users: Set registerTransactions: true in your Search request.

Use Audit Search Logs Functionality for log-level analysis, or audit transactions for request-level raw payloads.

Example (HotelX API):

query {
  hotelSearch(
    criteria: {...}
    auditTransactions: true
  ) {
    errors { code description type }
  }
}

3. Verify Portfolio and Mapping Coverage

• Ensure requested products/hotels are in the Seller portfolio.
• If needed, force an update.
• If using HotelX Pull Buyers API with your own context, confirm mapping is current in HotelX Mapping File Overview.

4. Validate Request Constraints

• Confirm market, nationality, date, and stay parameters are valid for Seller rules.
• Review any filters applied in your HotelX Search request, since restrictive filters can reduce or eliminate available results. Pay special attention to access, supplier, plugin, rateRules, currency, and status filters. For more details, see Search Filters.
• Re-test using criteria known to be allowed for your credentials.

5. Review Speed Configuration

• If your connection/access uses Speed, review current mode.
• Fast mode can increase no-availability outcomes because only cached responses are returned.
• Use Standard mode for troubleshooting and baseline validation.

6. Contact Seller With Evidence

• Share audited request/response examples and ask the Seller to confirm credential permissions and portfolio scope.

7. Escalate Persistent 204 Cases

• If 204 persists after completing the checks above, contact Customer Support with:
  • Request/response logs
  • Audit evidence
  • Seller successful availability references for matching criteria

After incident recovery, continue with the optimization playbook to reduce future no-availability rates.

How to Obtain Seller Logs in Their Own Format

Use the auditData parameter in the HotelX Pull Buyers API or registerTransactions in the Legacy Pull Buyers API. Detailed instructions are available in Audit Supplier Transactions.

Why Do I Receive No Availability (No results found) Through Travelgate When the Seller's Website Returns Results?

It is essential to understand that Travelgate acts primarily as a technological bypass. Our platform connects your request directly to the Seller’s API and delivers the response they return to us. Availability on a web interface does not guarantee availability via an API integration for the following reasons:

1. Inventory Segmentation by Channel
   Many Sellers manage separate inventories for their direct sales channels (B2C websites) and their XML/API distribution channels. A product may be available to the general public on a website but restricted or sold out for third-party technological integrations.

2. Credential and Contract Specifics
   The availability you receive through Travelgate is tied exclusively to the credentials provided to you by the Seller. The inventory returned is linked to your specific contract, assigned market, and negotiated commercial conditions. A search on a Seller’s public website often uses generic criteria that may not match your API access.

3. Differences in Product Portfolio
   Not all hotels or room types displayed on a Seller’s website are necessarily open for API distribution. If the requested product is not part of the portfolio activated for your specific integration, the Seller will not return results via the API.

4. API-Specific Business Rules and Filters
   Sellers often apply specific business logic—such as market restrictions, passenger nationality requirements, or minimum lead-time rules—only to their API booking engine and not to their direct website.

5. Cache Layer (Speed)
   If you are using our Speed optimization solution, you may be receiving a cached response. In "Fast" mode, you will only see results already stored in the cache; if the data is not currently stored, Travelgate will return a 204 error even if the Seller has real-time availability.

info

If you have verified that your Search criteria (dates, occupancy, and market) are identical and the discrepancy persists, we recommend contacting the Seller directly. Ask them to verify if the product is explicitly enabled for your API credentials and not just for their web environment.

How to Handle 204 Errors in Quote Responses

1. Shorten Interval Between Calls

• Reduce the time between Search and Quote calls to minimize the risk of options becoming unavailable.

2. Check Seller Caching

• Confirm whether the Seller uses caching mechanisms that could be causing no availability errors.

3. Consider Peak Dates

• High-occupancy periods or last-minute searches may result in limited availability.

4. Review Speed Configuration

• If using Speed, check the TTL (Time to Live) settings and adjust them if needed. More details are available in How Speed Works.

For Sellers

How to Handle 204 Errors in Search Responses

1. Check Credentials

• Verify that the Buyer’s credentials are correctly configured on your end and match what they are using.

2. Verify Product Availability

• Ensure the requested product is part of your portfolio and is available based on the Buyer's specified search criteria. If discrepancies exist, force a portfolio update and ask the Buyer to remap.

3. Speed Configuration

• If your connection/access is enabled through the Speed cache feature, review your current Speed mode settings.
  • The "Fast" mode increases the likelihood of no availability results because it only displays cached responses.
  • If the data isn’t already stored, no results will appear—though the request is still forwarded to the Seller for future caching.
• Switch to the Standard speed mode (recommended) and monitor whether the availability ratio improves.

4. Update Mapping File

• If the Buyer is using HotelX API, they should ensure their mapping file is current. More details are available in HotelX Mapping Plugin Documentation.

5. Confirm Request Validity

• If your system shows availability but the Buyer does not receive it, they should audit their Search logs by setting auditTransactions to true. If discrepancies persist, they should provide:
  • Complete request and response no-availability logs.
  • Matching transactions from your side.
  • Identical product and search criteria.