APIM/API Hub caching stale error response for custom connector — data.gov.il proxy stuck on 404 since 2026-08-20

APIM/API Hub caching stale error response for custom connector — data.gov.il proxy stuck on 404 since 2026-08-20

Summary

A custom connector's proxied backend calls consistently return a stale, cached 404 error page via Power Platform's API Hub/APIM layer, while identical calls to the same backend succeed every time when made directly (browser or curl). The response header x-ms-apihub-cached-response: true confirms this is being served from Microsoft's own cache, not a live backend response.

Environment

• Connector: Independent Publisher, Israel Open Data (data.gov.il CKAN Action API, No Auth)
• Environment ID, Tenant ID, and Subscription ID: redacted from this public issue — happy to provide directly to a Microsoft engineer working the case, just not posted publicly here.
• Connector route: /apim/new-5fisrael-20open-20data-20temp-5f33a5b486ed68fe1a/{connectionId}/{operation}

Evidence

Direct call (browser/curl) to https://data.gov.il/api/3/action/organization_list → HTTP 200, valid JSON, every time.

The same operation called through the connector (Test tab or a flow) → HTTP 404, HTML body (Hebrew "page not found" page), with these response headers:

x-ms-apihub-cached-response: true
age: 53717
last-modified: Thu, 04 Apr 2024 13:53:01 GMT
x-cache: Error from cloudfront
via: 1.1 <hash>.cloudfront.net (CloudFront)

The Age value is inconsistent with elapsed wall-clock time between repeated tests, and Last-Modified is nearly 2.5 years old — this response is not being refreshed.

What we've tried (all failed to invalidate the cache)

1. New connection — created a fresh connection object; identical cached 404 returned.
2. Cache-busting request headers — added Cache-Control: no-cache and Pragma: no-cache via a "Set HTTP header" policy template on the request; the outbound request (checked via Test tab raw request) never actually carried these headers, suggesting API Hub serves the cached response before outbound policies run.
3. Explicit route rewrite — added a "Route request" policy template rewriting the backend path explicitly; identical result.
4. Connector republish / policy updates — no change.

Impact

This affects every operation on the connector, not just one route, and reproduces both in the connector's own Test tab and in a real flow run — meaning certification reviewers testing this connector would hit the same failure.

Ask

Please advise whether this is a known API Hub caching behavior/bug, how its TTL/invalidation works, and how a connector author can force invalidation (short of waiting an unknown, apparently very long duration).

No repository file, test, or code entry point is identified. Start by reproducing the discrepancy with the connector Test tab or a flow and compare it with the direct curl/browser request, including the listed cache headers. Done would be an explanation of the API Hub/APIM caching behavior and a documented invalidation path for connector authors.