Admin API Boundary Map

API7 Gateway exposes three distinct HTTP surfaces that all sit somewhere between "management API" and "admin API," on three different ports, with three different authentication models. Confusing them is an easy mistake: two of the three even share part of a name (/apisix/admin/* is served by the Dashboard, not by the APISIX Admin API it's named after). This page is a decision aid — which surface to call for a given task, and what happens if you reach for the wrong one. It is not a field-level reference; for that, use the links in each row.

For the full port, protocol, and firewall picture — including the ports these three surfaces don't cover, like the proxy ports and the status endpoints — see Ports and Endpoints. For a comparison of tools (Dashboard UI, ADC, a7 CLI, API7-MCP) rather than surfaces, see Management Options; several of those tools call the same surface described in the first row below.

The three surfaces

Which one do I call for X

• Create, update, or inspect routes, services, upstreams, consumers, SSL certificates, or plugins for a gateway group. Call the Dashboard Admin API on 7443, either directly against /apisix/admin/* with a gateway_group_id, or through ADC or the a7 CLI, which call the same surface. This is true regardless of which data-plane nodes ultimately serve the traffic.
• Manage users, roles, IAM policies, gateway groups themselves, tokens, or audit logs. Call the Dashboard Admin API's /api/* paths on 7443. These are control-plane resources with no APISIX-native equivalent.
• Manage API products, developer applications, subscriptions, or developer accounts in the Developer Portal. Call the Portal API backend on 4321 with a developer's Bearer token, or use the Developer Portal's own UI. This is a separate resource model from gateway groups and routes; the Dashboard Admin API does not manage Portal resources, and the Portal API backend does not manage gateway resources.
• You found port 9180 open on a data-plane node, or a runbook from an Apache APISIX (as opposed to API7 Gateway) deployment tells you to call it. Don't, on an API7 Gateway data plane — see the next section. It is not part of this documentation's supported surface, is disabled by default, and behaves nothing like the Dashboard Admin API even in APISIX release names it happens to share.

Why the APISIX-native Admin API (9180) is different, not just smaller

Ports and Endpoints already establishes that 9180 is Apache APISIX's own Admin API listener, that it ships disabled on an API7 Gateway data plane, and that reaching it is not part of this documentation's supported surface. What follows here is what happens if it is manually enabled anyway — tested directly, since no reviewer had previously verified its behavior — so that a decision to enable it, or a firewall rule to keep it closed, is made on evidence rather than assumption.

This was verified against the open-source apache/apisix:3.18.0-debian image with etcd, not against an API7 Gateway data-plane image or with an Enterprise license — because 9180 is the upstream Apache APISIX Admin API code path, and API7 Gateway's data plane does not modify it. The result describes that shared code path.

No Dashboard token, no gateway group, no audit trail. The Dashboard Admin API's X-API-KEY is a per-user token issued from the Dashboard, scoped by IAM policy and logged to the audit trail. The APISIX-native Admin API's X-API-KEY is a single shared secret matched against a static admin_key list in the data plane's own config.yaml — there is no per-user identity, no IAM check, and no audit log entry for a write made this way.

gateway_group_id isn't rejected — it's invisible. A request to /apisix/admin/routes on 9180 with a ?gateway_group_id=... query parameter returns exactly the same result as the same request without it: the parameter is silently ignored. The APISIX-native Admin API has no concept of a gateway group at all. Every write through it lands in one global route table on that data-plane node's own etcd — not scoped, filtered, or partitioned by anything the Dashboard understands. A resource written through 9180 does not appear in, and is not managed by, the Dashboard.

Two layers of defense, IP allowlist first. By default, enable_admin is true and allow_admin is ["127.0.0.0/24"] in the underlying APISIX configuration — meaning the listener exists, but only loopback-range traffic reaches the key check at all. A request from outside that range is rejected with 403 Forbidden by the IP allowlist before the API key is ever examined, regardless of whether the key is correct. Enabling 9180 without also widening allow_admin does not expose it beyond the node itself; widening both together does expose an endpoint with none of the Dashboard Admin API's tenancy or audit guarantees to whatever network can reach it.

The observed responses, for anyone building tooling that has to handle them: no key returns 401 with {"description":"missing apikey","error_msg":"failed to check token"}; a wrong key returns 401 with {"description":"wrong apikey", ...}; a correct key returns normal Admin API JSON with an X-API-VERSION: v3 header.

Related

• Ports and Endpoints — the authoritative port table this page's surfaces are drawn from, including firewall direction and the configuration key for each listener.
• Management Options — comparing the tools (Dashboard UI, ADC, a7 CLI, API7-MCP) that call the Dashboard Admin API, rather than the surfaces themselves.
• Obtain a Token from the Dashboard — creating the token the Dashboard Admin API and ADC both use.
• Admin API Reference and Developer Portal API Reference — the full endpoint references for the first two surfaces.
• Role-Based Access Control and Permission Policies and Boundaries — the IAM model that scopes Dashboard Admin API access, which the APISIX-native Admin API has no equivalent of.