Proposal: Minimal guardrailed request enrichment for APISIX (not full orchestration)

[vahidaghazadeh]

Hi APISIX maintainers,

Thanks again for taking the time to review my previous PR (#12128). I understand the concern that full service orchestration usually belongs outside the gateway layer.

I’m not trying to reopen that PR in its original form.
What I want to ask here is simpler: would a much smaller, tightly limited version make sense in APISIX, or should this stay external?

Why I’m asking
In a few real-world cases, we need one lightweight enrichment step before proxying upstream. For example:

resolving/validating a token via an internal auth endpoint
fetching a small tenant/profile attribute needed by upstream logic
injecting a derived header/field for downstream services
Yes, this can be done in BFF/service code (and often should be).
But teams still end up re-implementing similar gateway-side logic in custom scripts/plugins.

Narrow proposal (discussion only)
If this is considered at all, I think it should be very constrained:

single-step only (no multi-hop chain)
fail-fast only (no complex recovery flows)
strict limits (timeout, max response size, optional short-circuit)
explicit contract (JSON-only or clearly defined non-JSON behavior)
performance guardrails (keepalive/pooling, observability/metrics)
clear docs positioning (not a replacement for BFF/orchestration)
What I need guidance on
Is a single-step enrichment plugin still out of scope for APISIX?
If yes, would you prefer this to remain an external plugin with best-practice docs?
If potentially in scope, what hard constraints would you expect before a new proposal/PR?
I want to align with APISIX architecture first, before spending more implementation effort.

Thanks again for the guidance.