API7 Enterprise 3.10.0: Simpler Service Management, Stronger Security, and Better AI Traffic Reliability

Key Takeaways

• API7 Enterprise 3.10.0 simplifies service management by removing Service Templates and API Publishing, so services are managed directly under gateway groups.
• The release strengthens security posture through safer authentication defaults, encrypted sensitive fields, identity-header hardening, and clearer cache behavior.
• AI Proxy and AI Proxy Multi improvements make AI traffic more reliable through stable request encoding and DNS-aware upstream selection.
• Developer Portal behavior is more explicit: developer authentication applies only to published API products, reducing hidden draft-product assumptions.
• Upgrade planning should focus on service ownership, authentication clients, cache behavior, Developer Portal publishing, and custom runtime configuration.

Enterprise API platforms get complicated when service ownership, publishing workflows, runtime policy, and traffic operations live in separate layers. One team may own service templates. Another may publish API products. Platform operators still need to understand which gateway group, service, route, plugin, and policy affect a production request. That complexity becomes more visible as the same gateway layer starts handling product APIs, partner APIs, LLM traffic, and MCP tool access.

API7 Enterprise 3.10.0 addresses that problem with three practical release themes: simpler service management, stronger security defaults, and better AI traffic reliability. The most important change is not cosmetic. Service Templates and API Publishing are removed, and Services are managed directly under gateway groups. Around that core model change, the release also tightens authentication, cache behavior, Developer Portal publishing rules, and AI traffic handling.

This makes API7 Enterprise 3.10.0 an operations-focused release. It reduces the number of concepts platform teams need to reason about, while improving the default behavior of the traffic paths they already run in production.

flowchart LR
    group[Gateway Group] --> services[Direct Services]
    services --> routes[Routes and Plugins]
    routes --> apis[API Traffic]
    routes --> ai[AI Traffic]
    portal[Developer Portal] --> products[Published API Products]
    products --> services
    console[Console Policy Editor] --> group
    services --> security[Security and Cache Defaults]
    services --> ops[Upgrade Review]

Simpler Service Management

The biggest API7 Enterprise 3.10.0 change is the removal of the Service Template / Service Hub model and the API Publishing mechanism. Services now belong directly to gateway groups and are managed through the APISIX Admin API. In the Console, the Service Hub area is replaced by a Services list under each gateway group.

This matters because service management is where daily API operations meet organizational ownership. Platform teams need to know where a service lives, which routes and plugins belong to it, and which gateway group is responsible for running it. The previous template and publishing layers could standardize workflows, but they also added distance between the configuration people edited and the runtime service behavior people had to troubleshoot.

During upgrade, existing service templates and published services are automatically migrated to the new direct-service model. Original data is preserved for rollback, and IAM policies that reference service-template or published-service ARNs are backed up and rewritten. That migration path is important: the release changes the mental model without asking operators to manually recreate every service relationship.

The Console also reinforces this simpler operating model. Compatibility warnings now show affected resources using their business hierarchy path, such as gateway group, service, and route, instead of only showing raw resource IDs. Administrators also get a visual editor for permission policy statements, so they can build IAM policies by selecting resource types, actions, and conditions rather than writing JSON by hand.

flowchart LR
    before[Before 3.10.0: Service Template and API Publishing Layers] --> migrate[Upgrade Migration]
    migrate --> after[After 3.10.0: Services Under Gateway Groups]
    after --> routes[Routes, Plugins, and Runtime Traffic]
    after --> iam[IAM Policy Review]
    after --> console[Console Compatibility Paths]

Stronger Security Defaults

API7 Enterprise 3.10.0 also tightens several security-sensitive behaviors. These are not all new headline features, but they reduce the kind of ambiguity that can become expensive in production.

First, hmac-auth now defaults signed_headers to ["date"]. After upgrading, any hmac-auth configuration that does not explicitly set signed_headers requires clients to sign the Date header. That is a stronger default for request validation, but it is also an upgrade item: clients that did not previously sign Date may start receiving HTTP 401 responses unless the plugin configuration is adjusted.

Second, API7 Enterprise continues to reduce sensitive-field exposure when data encryption is enabled. In 3.10.0, secret_fallbacks for Feishu Auth and DingTalk Auth are encrypted at rest. The practical value is straightforward: credential-like fields should not remain in plaintext in etcd, backups, or exports when encryption is enabled. Operators should upgrade control plane and data plane together, or upgrade data planes before relying on newly encrypted fields, so older data planes do not treat ciphertext as the real secret.

Third, identity headers are safer. Feishu Auth now clears any client-supplied X-Userinfo header before authentication, helping ensure upstream services receive identity information controlled by the plugin rather than by the caller. For teams building zero trust API architectures, this detail matters: identity propagation should come from validated authentication, not from headers a client can forge.

Cache behavior is also part of security. API7 Enterprise 3.10.0 adds Vary response header support to the in-memory Proxy Cache strategy. Responses are cached by variants listed in Vary, while Vary: * responses are not cached. That makes caching more correct for APIs where response representation depends on request headers. If you use GraphQL Proxy Cache or authenticated API caching, this is a good moment to review cache-key assumptions as part of the upgrade.

Better AI Traffic Reliability

LLM traffic is harder to operate when every application talks directly to model providers. A small change in request formatting can affect provider-side caching. DNS behavior can influence endpoint selection. Streaming response handling can change perceived latency. Large request bodies can put pressure on gateway and application performance.

API7 Enterprise 3.10.0 improves this path through the AI Proxy plugin. The plugin now JSON-encodes upstream LLM request bodies with sorted keys. For equivalent requests, this creates a stable byte-identical payload. That matters because some LLM providers base prompt-cache behavior on the exact request body. When provider-side caching is available, stable request encoding can help teams improve cache hit rates for repeated prompts and reduce unnecessary model work.

AI Proxy Multi also improves endpoint handling. When an LLM endpoint domain resolves to multiple A records, the plugin now resolves all of them and builds a multi-node upstream, selecting a node per request. The Host header and TLS SNI continue to use the original domain name. For platform teams, this supports better load distribution and failover behavior when model endpoints sit behind DNS-based distribution.

The value is not simply that AI Proxy changed request formatting. The larger value is reliability. Application teams can call a governed internal endpoint while platform teams manage provider routing, authentication, request normalization, DNS behavior, and observability in one place. This is especially important as enterprises standardize API7 AI Gateway usage across teams rather than letting every application build its own direct model-provider integration.

sequenceDiagram
    participant App as Application
    participant GW as API7 AI Gateway
    participant DNS as DNS Resolver
    participant LLM as LLM Provider Endpoints

    App->>GW: OpenAI-compatible or provider-specific request
    GW->>GW: Normalize JSON body for stable cache behavior
    GW->>DNS: Resolve provider domain
    DNS-->>GW: Return multiple A records when available
    GW->>LLM: Route request to selected upstream node
    LLM-->>GW: Return model response
    GW-->>App: Return governed response with gateway context

AI reliability also includes tool exposure. The OpenAPI to MCP plugin helps teams expose OpenAPI-based services through an MCP interface while keeping gateway policy in the path. A closely related release-line improvement added allowed_hosts for dynamically resolved base_url values, restricting which hosts a dynamic base URL may target and rejecting malformed or non-HTTP(S) URLs. As agentic workflows grow, this kind of boundary helps keep tool access governed rather than ad hoc.

Clearer Developer Portal and Operations Behavior

Service governance is only useful if it fits daily platform operations. Once services are managed directly under gateway groups, the surrounding workflows also need to be explicit: which API products require developer authentication, which policies apply to which resources, and where operators should look when compatibility issues appear.

Developer Portal behavior also becomes more explicit. In the Developer Portal, developer authentication is now enforced only for published API products. Previously, draft API products could also sync developer authentication rules to the gateway, so routes belonging to a draft product required developer authentication. After upgrading, routes in draft API products no longer require developer authentication until the product is published. Teams that relied on draft products being protected should publish those products or restrict access through another control before upgrading.

The Console also gained a visual editor for permission policy statements. Administrators can build IAM policies by selecting resource types, actions, and conditions instead of hand-writing JSON. Compatibility warnings now show affected resources with their business hierarchy path, such as gateway group, service, and route, making it easier to locate configuration issues.

For runtime troubleshooting beyond configuration review, platform teams can also use Debug Sessions as part of daily gateway operations.

What to Review Before Upgrading

The best way to treat API7 Enterprise 3.10.0 is as both a product upgrade and a governance checkpoint. Before upgrading, review the release notes carefully and validate the areas most likely to affect production behavior:

• Service Templates and API Publishing have been removed and migrated to the direct-service model.
• Developer authentication now applies only to published API products.
• The Data Plane runtime has been upgraded to OpenResty 1.29.2.4. Custom NGINX snippets should be checked for compatibility.
• hmac-auth now requires signing the Date header by default unless signed_headers is explicitly configured.
• If data encryption is enabled, plan control plane and data plane upgrades carefully so newly encrypted plugin fields are handled by compatible data planes.
• If you use Proxy Cache or GraphQL Proxy Cache, review cache-key assumptions before enabling or tuning caching for authenticated API traffic.

flowchart TD
    start[Plan 3.10 Upgrade] --> services[Review service model migration]
    services --> portal[Check Developer Portal draft product behavior]
    portal --> nginx[Validate custom NGINX snippets with OpenResty 1.29.2.4]
    nginx --> encryption[Plan encrypted field compatibility]
    encryption --> hmac[Confirm HMAC clients sign Date header]
    hmac --> ai[Validate AI Proxy routes and model endpoints]
    ai --> cache[Review Proxy Cache and GraphQL cache settings]
    cache --> staging[Test gateway groups and data planes in staging]
    staging --> release[Proceed with production rollout]

This upgrade review should include gateway configuration, plugin usage, client authentication behavior, Developer Portal workflows, and automation scripts. Teams operating hybrid, multi-cluster, or Kubernetes-based environments should also validate Data Plane compatibility and deployment charts in a staging environment before production rollout.

Conclusion

API7 Enterprise 3.10.0 matters because API management becomes harder when service ownership, publishing workflows, traffic policies, and runtime behavior are split across too many layers. This release moves the core service model in a simpler direction while tightening important gateway defaults.

The release strengthens API7 Enterprise as a gateway-level governance layer for this operating model. Service management becomes more direct. Security defaults become stronger. Developer Portal publishing rules become more explicit. LLM traffic becomes more predictable. MCP exposure gains clearer boundaries. Cache behavior becomes more correct. Operators gain clearer configuration and policy management in the Console.

Read the full API7 Enterprise release notes, review the upgrade guidance for your environment, and explore the API7 AI Gateway and Developer Portal documentation to plan your next rollout.