The developer portal listed this API with no reference documentation:
catalog was the only domain that had a spec anywhere in the tree.
Generated from the backend's own drf-spectacular schema
(/classic-models/api/schema/, version 4.7.0), filtered to the operations
this domain's gateway actually exposes — derived from the Kong routes and
their request-transformer rewrites in Konnect, not from guesswork. Every
route resolved to a backend operation; the counts match one for one.
Paths and server are the **gateway's**, not the backend's. A portal
reader calls https://customers-dev.sttlab.local/customers/v1/..., and the
gateway rewrites that onto /classic-models/api/v1/... upstream. Path
parameters are renamed to the gateway's capture names where the backend
used a different case.
Components are pruned to what these paths transitively reference.
Note: catalog-api/openapi.yaml does NOT follow this convention — it
documents the backend paths and http://localhost:8000 as its server, so
its operations cannot be called as written from the portal. Left alone
here; worth aligning separately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CONTROL_PLANE_REF_NAME held the random suffix the Gateway operator gives
its auto-created mirror CR, looked up by hand. Replacing the Konnect org
recreated those CRs under new suffixes, so the ref named an object that
no longer existed and the domain's Kong entities sat Programmed=False.
Name the ${NAME}-cp mirror declared in k8s-platform's dataplane-template
instead — derived from NAME, so it stays valid across Gateway
recreations and Konnect org changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Post http-log to /customers instead of /logs. Fluent Bit's http input derives the
record tag from the request URI, so the path is what identifies this domain
in the collector and becomes the Loki label domain=customers.
The collector keeps writing every domain to the on-disk audit trail as
well, so this is reversible by restoring the previous path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The second ai-mcp-proxy binding (added to fix the GET/SSE 502 loop)
created a second runtime plugin instance with the same tool config,
which ai-mcp-proxy's own duplicate-name detection caught: all three
tools (list-customers/get-customer/create-customer) fell back to
auto-generated names across both instances. Confirmed via dataplane
pod logs right after applying the previous fix.
Real fix: one KongRoute for all three MCP HTTP methods (GET/POST/
DELETE) instead of two, one ai-mcp-proxy binding instead of two.
ai-mcp-proxy already tolerates multi-method routes (same "skips
method selection" notice the existing POST+DELETE route already
produces) — extending to GET is the same class of thing, not new
risk, and there is now exactly one plugin instance so no duplicate
tool names.
The stream route (GET, mcp/routes.yaml) had no ai-mcp-proxy binding,
so GET requests fell through to the KongService's own upstream
target (REST_HOSTNAME, i.e. Kong's own external hostname) and
looped back into the Gateway, growing response headers each pass
until nginx rejected them (502, "upstream sent too big header").
Confirmed via customers dataplane pod logs while debugging a
LibreChat connection failure. catalog-mcp has the same structural
gap but happens to 405 instead of looping there — not touched here.
8 routes over Customer + orders/payments sub-resources, proxying to
classic-models-api. openid-connect with RFC 8693 token exchange to
classic-models-api audience, rate-limiting, proxy-cache, audit-log —
same plugin set and structure as catalog-api's REST surface.
Not deployed: dev/gitrepository.yaml points at a gitea repo that
doesn't exist yet (kong-customers-api.git, 404). No MCP layer yet
either, unlike catalog-api.
Stéphane Tailland