[Bug]: Inconsistent API key name/handle length constraints across platform-api, gateway, api-portal, and ai-workspace

Please select the area the issue is related to

Platform API

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Description

The maximum allowed length for an API key name (handle) is defined differently across the components that participate in API key creation, and there is no single source of truth. This was surfaced while working on #3163 / PR #3215.

Note on Area: the issue template only allows selecting a single Area, but this problem spans platform-api, ai-workspace, gateway, and api-portal (Dev Portal). Selecting "platform-api" as the primary area since that's where the missing validation causes the most immediate failures, but please add the other components as additional labels/mentions if the label set allows it.

Current state per component:

Because of this mismatch:

• A name that is valid per the Dev Portal (up to 128 chars) can be silently accepted by the Platform API (no validation) and then rejected or truncated by the Gateway (63-char limit) or fail to persist correctly against the 40-char DB column.
• A name that is valid per the Gateway's 63-char limit can still exceed the Platform API's 40-char DB column, risking truncation or DB-level constraint errors depending on how/when validation is added.
• There is currently no single component that validates against a range all downstream components can actually accept end-to-end.

This issue is to track resolving the inconsistency itself (choosing one canonical max length and propagating it correctly, including any required DB migration), separate from the narrower validation-gap fix in #3163, which only needs to enforce the existing 3–40 range in platform-api and ai-workspace without changing the DB schema.

Related: #3163, PR #3215 (closed — see PR discussion for full analysis)

Steps to Reproduce

1. Open the Dev Portal (API Portal / Console) and navigate to API Key creation for a given application/subscription.
2. Enter an API key display name longer than 63 characters but no more than 128 characters (e.g. a 100-character name). The Dev Portal accepts this, since its field allows up to 128 characters.
3. Submit the request; the Dev Portal calls the Platform API to create/generate the corresponding handle.
4. Observe that the Platform API does not reject the caller-supplied/derived handle for exceeding its own 3–40 character constraint (no code-level validation exists), even though its OpenAPI spec and DB schema (api_keys.handle VARCHAR(40)) only support up to 40 characters.
5. The Platform API forwards the handle to the Gateway to register the API key.
6. Observe one of the following failure modes at the Gateway, depending on the generated handle's length:
   • If the handle is between 41–63 characters: Gateway accepts it (within its 3–63 range), but it cannot be persisted correctly by the Platform API's 40-char DB column, risking truncation or a DB constraint error.
   • If the handle exceeds 63 characters: Gateway rejects the request outright, since it enforces both the 63-character limit and the ^[a-z0-9]+(-[a-z0-9]+)*$ naming pattern at validation and DB level.
7. Separately, repeat steps 1–3 via the ai-workspace portal for LLM API keys / proxy API keys: the same absence of independent validation means the same downstream failure can occur through this path as well.
8. Compare this against directly calling the Platform API with a handle between 41-128 characters: the request is accepted (no service-side validation), confirming the root inconsistency is not UI-specific but exists in the Platform API service layer itself.

Result: API key names that appear valid at the point of entry (Dev Portal or ai-workspace) can fail, silently truncate, or be inconsistently accepted depending on which downstream component (Platform API DB, Gateway) they pass through next, because no two components share the same length constraint and the Platform API layer performs no validation at all.

Severity Level of the Issue

Severity/Major (Important functionality is broken. Should be prioritized. Doesn't need immediate attention)

Environment Details (with versions)

• Repository: wso2/api-platform (monorepo)
• Affected components and versions/paths:
  • platform-api — internal/service/apikey.go, internal/database/schema*.sql (postgres, sqlite, sqlserver, default), resources/openapi.yaml
  • gateway — gateway/gateway-controller (management-openapi.yaml, pkg/constants, pkg/utils/api_key*.go); Gateway release referenced: v1.0.0 (wso2apip-api-gateway-1.0.0)
  • portals/ai-workspace — src/utils/apiKeyName.ts, proxies/, serviceProvider/ pages
  • api-portal / Dev Portal (Console) — API key creation UI (displayName field)
• Databases affected (Platform API schema): PostgreSQL, SQLite, SQL Server, default schema.sql
• Observed/discussed: August 2026