How to list URLs for purge_cache

None of the following produce success. In each case, I get

"code": 1012,
      "message": "Request must contain one of \"purge_everything\", \"files\", \"tags\", \"hosts\" or \"prefixes\""

In every case, I do have either “purge_everything” or “files”, so the error message is not helping. What am I doing wrong?

[Including “hosts”, and “files” with “url”]

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"      
-H "Content-Type:application/json"      
-H "X-Auth-Key:<MY KEY>"   
-H "X-Auth-Email:<MY EMAIL>" 
--data '{"hosts":["mydomain.com"], "files":[{"url":"https://mydomain.com/my-file.php"}]}'

[Without “hosts”]

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"     
 -H "X-Auth-Email:<MY EMAIL>"    
 -H "X-Auth-Key:<MY KEY>"  
 -H "Content-Type:application/json" 
-H "Origin: https://www.cloudflare.com"  
--data '{"files":[{"url":"https://mydomain.com/my-file.php"}]}'

[purge_everything]

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"     
 -H "X-Auth-Email:<MY EMAIL>"    
 -H "X-Auth-Key:<MY KEY>"   
-H "Content-Type:application/json"  
--data '{"purge_everything":true}'

[purge_everything, with Origin]

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"      
-H "X-Auth-Email:<MY EMAIL>"    
 -H "X-Auth-Key:<MY KEY>"   
-H "Content-Type:application/json" 
-H "Origin: https://www.cloudflare.com"  
--data '{"purge_everything":true}

[files with { } ]

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"     
 -H "X-Auth-Email:<MY EMAIL>"    
 -H "X-Auth-Key:<MY KEY>"   
-H "Content-Type:application/json" 
-H "Origin: https://www.cloudflare.com"  
--data '{"files":[{"https://mydomain.com/my-file.php"}]}'

[files without { ] ]

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"     
 -H "X-Auth-Email:<MY EMAIL>"    
 -H "X-Auth-Key:<MY KEY>"   
-H "Content-Type:application/json" 
-H "Origin: https://www.cloudflare.com"  
--data '{"files":["https://mydomain.com/my-file.php"]}'

Bonus question - I want to list more than one URL - How to do that? (I also tried several combinations of { } and square brackets but no joy.

TIA

Could it be a permissions issue? When I curl just my authorisation details, the response list includes:

"#cache_purge:edit"

So shouldn’t that mean the curl commands should work?

For any plan but enterprise, you can only purge by file or everything. It should just be

--data '{"files":["https://www.example.com/file1" ,"https://www.example.com/file2" ]}'

You don’t need the origin header

2 Likes

Thanks for your reply. I’m doing one file only for now, like this:

curl -X GET "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache"      
-H "X-Auth-Email:<MY EMAIL>"     
-H "X-Auth-Key:<MY KEY>"   
-H "Content-Type:application/json"  
--data '{"files":["https://mydomain.com/my-file.php"]}'

But it still gives me the same code 1012 error.

Is my API set up wrong? the summary has:

All users - User Details:Read

Oops - that’s meant to be POST for the method, of course.

Looks like the token needs Edit permission. The API docs usually show you the permission you need for that call:

2 Likes

Thanks, sdayman.

I changed it to “All zones - Cache Settings:Edit”

Bit I still get the same old error,

"Request must contain one of \"purge_everything\", \"files\", \"tags\", \"hosts\" or \"prefixes\""

The Help dropdown under the API Tokens section says:

“API Tokens use the standard Authorization: Bearer header for authentication instead of x-auth-email and x-auth-key that API Keys use.”

However, I can’t get any joy from “Authorization: Bearer”, even for a simple authroisation check. My only successful call to this API so far has been using the email/auth-key combination.

On a related note, I’m trying to call the API from a PHP script, as follows:

$data = '{"files":[
  "https://mydomain/myscript1.php",
  "https://mydomain/myscript2.php"
]}';
        
$url = "https://api.cloudflare.com/client/v4/zones/{$zoneId}/purge_cache";
$opts = ['http' => [
    'method' => 'POST',
    'header' => [
        "Content-Type: application/json",
        "X-Auth-Key: {$authKey}",
        "X-Auth-Email: {$authEmail}",
    ]	,
    'content' => json_encode($data),
]];
$context = stream_context_create($opts);
$result = file_get_contents($url, false, $context);

The error I keep getting is:

Failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request

What’s wrong with the request?

I’m beginning to wonder if there is something wrong with the API?

Two updates:

(1) My PHP script works perfectly fine if I use method GET, so just like straight curl commands, it appears GET is fine while POST is not. Does that give any hints as to what the problem may be?

(2) I’m not the actual owner of the Cloudflare account that I’m calling (I have a sub-account) and I thought that may be the issue. But I also face the same errors when trying to do the same purge_cache call on my own account with my own zone.

When I do https://api.cloudflare.com/client/v4/memberships?status=accepted I can see the owner’s and my accounts have identical permissions, so I don’t think it’s that.

Can someone please help me with this? I’ve exhausted all the tests I can think of.

Either the API is broken, there is a permissions problem or there is something wrong with my curl statement.

Please help with any suggestions you have on how to solve it.

Thanks.

Your curl command works if you put a \ at the end of each line.

As you’re using the global API key, it’s not a token issue.

So it’s not the API.

Nope. I’m actually doing the following (on one line, due to Windows’ cmd multiline inability):

curl -X POST "https://api.cloudflare.com/client/v4/zones/<MY ZONE>/purge_cache" -H "X-Auth-Email:<MY EMAIL>" -H "X-Auth-Key:<MY KEY>" -H "Content-Type:application/json" --data '{"files":["https://mydomain.com/my-file.php"]}'

I separated the lines here on this forum so it was easier to read. So that’s not the issue.

Yes, I was confused at first about the role of tokens. I get it now about the global API key.

My credentials appear to be OK since I get correct responses when calling GETs, but the errors happen with POSTs. It won’t do “purge_everything” either - same error.

I copied and pasted what you just posted, and added my zoneID, email, and Global API, plus changed the hostname:

1 Like

Thank you again for sticking with this sdayman, and for trying it on your end.

Great that it works fine for you - now how do I get it to work for me?

I’ve now tried it in the 3 zones I am involved with and in each case it keeps telling me "Request must contain one of \"purge_everything\", \"files\", \"tags\", \"hosts\" or \"prefixes\""

But clearly my request contains “files” - why does the error keep saying I don’t? Same happens with “purge_everything”. It tells me I don’t have it, when I do.

I’ve tried it on another computer - same response.

My latest test was with the following data:

--data '{"hosts":["mydomain.com"], "tags":["some-tag"],"hosts":["mydomain.com"],"prefixes":["mydomain.com/directory"]}'

But still the result is:

"code": 1012, "message": "Request must contain one of \"purge_everything\", \"files\", \"tags\", \"hosts\" or \"prefixes\""

Yet I have host AND tag AND prefix in the data.

Also, the response complains (with a carat pointing to the “s” of “some-tag”):

curl: (3) bad range in URL position 7: tags:[some-tag],hosts:[mydomain.com],prefixes:[mydomain.com/directory]}'

It appears to be expecting a URL in the “tags” array.

Looking forward to getting this sorted.

Can someone please help me with this?

Surely there must be a way to test whether it’s a permissions issue (even though it tells me I do have purge_cache editing rights) or a technical issue.

So far, the only thing it tells me is:

  • I don’t have “files” when indeed, I do.
  • I don’t have “purge_everything” for the cases when I have actually specified it.
  • I don’t have “hosts”, “tags” or “prefixes” when in fact, I have all 3 of them.

So there’s a problem somewhere with the API, despite the fact most other people must be able to get it to work. I can’t.

Anyone else experienced such a thing? If so, how did you fix it?

Any help would be appreciated.

Still no resolution to this.

Surely there must be some way I can test why the API is failing for me?

The permissions seem fine, but the errors I’m seeing don’t follow from what I’m sending to the API.

I’ve got people waiting on successful implementation of the API and I’d really like to get it sorted.

My latest (of many) attempts to get some response other than code 1012 is as follows:

curl -X POST "https://api.cloudflare.com/client/v4/zones/myzone/purge_cache" -H "Content-Type:application/json" -H "X-Auth-Key:<my key>" -H "X-Auth-Email: <myemail.com>" --data '{"files":[ "https://mydomain.com/myfile.php", {"url": "https://mydomain.com/myfile.php", "headers": { "Origin": "https://www.cloudflare.com", "CF-IPCountry": "AU", "CF-Device-Type": "desktop" } }]}'

At least this gives me a different response. Hopefully it will give someone a hint about why the API does not work.

(1) The response that comes back is the (entire) page source from a page on my site

(2) But it’s not the source of the “myfile.php” page, rather it is the source for my “404 page not found” (even though the page I’m giving it is a correct URL, and doesn’t result in a 404).

(3) At the end, it says:

curl: (3) unmatched brace in URL position 1:
{url:
 ^

However, the braces ARE matched, and I’m following exactly the syntax given in Cloudflare API v4 Documentation

The request was ending in a 404 because there was a comma at the end of the URL that arrived at the server.

Can anyone please help?

This one wasn’t valid JSON due to having a duplicate hosts key.

It just sounds like an issue with your terminal & how it’s parsing or escaping your JSON. Try putting your JSON payload in a file and referring to it that way, like -d @data.json.

Thanks, KianNH.

Indeed, that was the problem - Windows command was messing up the data. Putting it in a separate file did the trick.

Thank you so much.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.