Cache purge API ignores Cloudflare for SaaS URL

Hey there,

I’m trying to purge cache for a URL that is served by my zone via Cloudflare for SaaS. When I call the " Purge Files by URL" endpoint with the following body, it results in success but doesn’t actually clear the cache for that URL.

curl -X POST "https://api.cloudflare.com/client/v4/zones/851d46c681b3da6a9fdebc07fa7f9530/purge_cache" \
     -H "Authorization: Bearer MY_API_KEY" \
     -H "Content-Type: application/json" \
     --data '{"files":["https://some.shaap.app/wp-content/themes/storefront/assets/css/base/icons.css?ver=4.1.1"]}'

Results in:

{
    "success": true,
    "errors": [],
    "messages": [],
    "result": {
        "id": "851d46c681b3da6a9fdebc07fa7f9530"
    }
}

But the cache doesn’t get cleared for that URL. If this is not the right way to clear cache for a URL hosted by Cloudflare for SaaS, what is?
PS: I’m not interested in “purge all”.

Thank you!

Hello - we’d like to look into this for you to see what’s going on. Would you mind confirming which URL you’re hitting that’s not getting purged (assuming it’s different than what’s posted above). Just want to make sure we’re looking in the right place to see what’s going on. Thanks!

It’s the same URL that’s listed as files parameters above. I’ve tried this with other URLs, basically, any URL that’s is part of a domain hosted by Cloudflare for SaaS doesn’t get cleared by this endpoint.

Is the URL involved in a multi-cdn configuration or setup via the saas config (more info here - Cloudflare for SaaS · Cloudflare for SaaS docs) Looking at the url appears that it is cached on limelight (CDN Finder - CDN Planet) so I’m trying to understand if that’s a possibility here?

Yeah, I switched to Limelight because of this problem with Cloudflare. I’ve switched it back to Cloudflare now if you want to debug.

Tried to purge the cache with the following params:
URL: https://api.cloudflare.com/client/v4/zones/851d46c681b3da6a9fdebc07fa7f9530/purge_cache
Method: POST
Body:

{
    "files": [
        "https://some.shaap.app/"
    ]
}

The API replied with the following:

{
    "success": true,
    "errors": [],
    "messages": [],
    "result": {
        "id": "851d46c681b3da6a9fdebc07fa7f9530"
    }
}

But the URL was not actually cleared from cache.

think we’ve found the issue. In previous configurations did you ever have Automatic Platform Optimization on? We think a configuration for that feature is causing this

can you please try to turn APO on and then uncheck the
“cache by device type” box above the red line in the pic above (if you look close you can see it’s checked). then you can turn APO off again if that’s what you want. I think this is including device type in your cache key which your purge request is missing which means there is a mismatch between what’s on cache and what you’re trying to purge… which is why the cache isn’t getting removed.

I’ve turned the APO feature off along with the “Cache by Device Type” flag. I also did a “Purge Everything” on the caching page which clears the cache for the whole zone. But once the cache is populated again and I try to purge it via API, it doesn’t work.
Here is my latest request:

{
    "files": [
        "https://some.shaap.app/shop/"
    ]
}

Response:

{
    "success": true,
    "errors": [],
    "messages": [],
    "result": {
        "id": "851d46c681b3da6a9fdebc07fa7f9530"
    }
}

But the cache for https://some.shaap.app/shop/ was not actually cleared.

Ignore the above, please! I thought I had it working but no

Ok, we continued to investigate and have another theory -

So your website is real.pk which has a worker is cnamed to some.shaap.app which is what you are trying to purge but THAT domain also has a worker that fetches https://50k9lazrzc.execute-api.us-east-1.amazonaws.com/.

This means the url you need to purge is https://50k9lazrzc.execute-api.us-east-1.amazonaws.com/ . We have confirmed purging this amazon url purges https://some.shaap.app/ in lab tests. For other urls you are trying to purge, I think you need to look at the worker to figure out what url you are actually fetching at the end to inform the purge.

This is the very common issue where customer tries to purge eyeball url instead of whatever url is in the fetch. This is a known issue and has caused issues with customers in the past. We’re looking to improve this experience soon.

1 Like

Thank you! It seems obvious now that I see it! :sweat_smile:

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