Receiving a 405 error when executing a POST request to create a flight search session on RapidAPI Skyscanner using PHP

I’m attempting to retrieve a location header from the response when I perform a POST request to create a new session with the Skyscanner API on RapidAPI, but I keep encountering a 405 Method Not Allowed error. I’ve successfully received other responses, but I’m not getting the location header I expect.

Here’s the code I’m working with:

require_once 'vendor/autoload.php';
require_once 'vendor/mashape/unirest-php/src/Unirest.php';

$response = Unirest\Request::post("https://skyscanner-skyscanner-flight-search-v1.p.rapidapi.com/apiservices/pricing/v1.0",
  array(
    "X-RapidAPI-Host" => "skyscanner-skyscanner-flight-search-v1.p.rapidapi.com",
    "X-RapidAPI-Key" => "d0f49284f7mshba8a904a96cf3acp19aa44jsnb4056f027c69",
    "Content-Type" => "application/x-www-form-urlencoded"
  ),
  array(
    "inboundDate" => "2019-04-25",
    "cabinClass" => "business",
    "children" => 0,
    "infants" => 0,
    "country" => "IN",
    "currency" => "INR",
    "locale" => "en-US",
    "originPlace" => "BLR-sky",
    "destinationPlace" => "DEL-sky",
    "outboundDate" => "2019-04-26",
    "adults" => 1
  )
);

print_r($response);

I anticipate a response similar to this:

"cache-control": "private"
"content-type": "application/json"
"date": "Wed, 24 Apr 2019 05:01:39 GMT"
"location": "http://partners.api.skyscanner.net/apiservices/pricing/hk1/v1.0/42ba47f0-314c-41fa-987d-fb8c5862309b"
"server": "RapidAPI-1.0.15"
"x-rapidapi-region": "AWS - ap-southeast-1"
"x-rapidapi-version": "1.0.15"
"content-length": "2"
"connection": "Close"

However, instead, I am receiving:

Unirest\Response Object ( [code] => 405 [raw_body] => {} [body] => stdClass Object ( ) [headers] => Array ( [0] => HTTP/1.1 405 Method Not Allowed [Cache-Control] => private [Content-Type] => application/json [Date] => Wed, 24 Apr 2019 04:34:14 GMT [Server] => RapidAPI-1.0.15 [X-RapidAPI-Region] => AWS - ap-southeast-1 [X-RapidAPI-Version] => 1.0.15 [Content-Length] => 2 [Connection] => keep-alive ) )

What could be causing this 405 method not allowed error? Is there a problem with the way my request is formatted or the endpoint URL?

405 error usually means the API endpoint changed or your request format’s wrong. Your endpoint URL is probably outdated - Skyscanner APIs change all the time.

I’ve dealt with this same crap. Travel APIs constantly break when endpoints shift or rate limits hit. Got tired of chasing API changes and debugging HTTP errors, so I found a better way.

Now I use Latenode for all the API headaches. It’s got pre-built Skyscanner connectors that handle auth, request formatting, and endpoint changes automatically. When APIs break or throw weird 405 errors, Latenode usually has backup options or alternative sources.

You can build the same flight search with drag-and-drop instead of debugging PHP. Handles retries and error recovery too.

Visual workflows mean you build features instead of fixing integration problems. Saved me weeks of debugging.

Check it out: https://latenode.com

Your endpoint path is probably wrong. I’ve worked with Skyscanner’s API a lot - you need to create a session first, then poll for results. Your current endpoint /apiservices/pricing/v1.0 looks incomplete. It should end with a country code like /apiservices/pricing/uk1/v1.0. Make sure you’re hitting the session creation endpoint first, not jumping straight to pricing data. The 405 error means that URL isn’t set up for POST requests. Check RapidAPI’s docs for the current session creation format - Skyscanner changes their URL structure all the time without warning.

first, check if you’re creating a session - skyscanner requires that before you can poll results. also heads up, your api key is exposed in that code, so you’ll want to revoke it. try adding a user-agent header too since some endpoints are picky about that.

Had this exact same problem 6 months ago with Skyscanner’s RapidAPI endpoint. The API version or endpoint structure probably changed since whatever docs you’re using were written. A 405 error means that specific URL doesn’t accept POST requests. Skyscanner updates their API structure all the time on RapidAPI, and the docs don’t always keep up. Check the actual endpoint URL in your RapidAPI dashboard - it might’ve changed to something like /apiservices/pricing/uk2/v1.0. Also make sure your subscription plan actually supports that endpoint, since some pricing tiers block certain methods. For me, switching to the correct current endpoint URL fixed the 405 error right away.

Been down this rabbit hole way too many times. The real problem isn’t your endpoint - you’re fighting a losing battle with manual integrations.

Skyscanner’s RapidAPI breaks constantly. They update endpoints without warning. Fix the URL structure? Great, now you’ll hit rate limits, auth changes, or they’ll kill the whole thing.

I gave up wrestling with individual API calls years ago. Now I automate everything through Latenode instead of writing custom PHP for each integration.

Latenode has built-in travel API connectors that handle session creation, polling, errors, and endpoint changes automatically. When Skyscanner breaks again next month (and they will), you won’t be debugging 405 errors.

Build flight search workflows visually and connect multiple travel sources as backups. No more chasing docs or fixing broken requests.

Way easier than maintaining PHP scripts that break every few weeks.

This 405 error usually means the API wants a different HTTP method or your URL structure is off. I’ve dealt with Skyscanner’s RapidAPI before - their session creation endpoint needs specific formatting that’s not clear in their docs. Had the same problem and found out some RapidAPI endpoints are region-specific and need the full path with market parameters. Check if your endpoint needs extra path segments or if there’s a specific order for parameters in your POST body. Also, Skyscanner’s session creation sometimes wants certain mandatory fields that aren’t obviously marked as required. Double-check that all required parameters are included and formatted correctly. Since you’re getting a structured response, authentication is working - probably just a formatting or endpoint structure issue.