Portal Applications
A Portal Application is the record created by a Portal account/developer to subscribe to API products and obtain API keys. This page describes managing Portal Applications from the Identity menu.
Portal Applications can be reached from two different menus:
- Identity > Applications: A view focused on the credential/API key side of applications. This view does not show API product/plan information.
- Portal > Applications: The same records in the context of Portal management; API product subscriptions are also shown here.
Both menus lead to the same application records; the creation, editing, deletion, and metadata operations described below apply to both views.
Application Types
Every application carries a Type, which decides who owns it and where it is visible:
| Type | Description |
|---|---|
| Portal | The ordinary consumer application. It belongs to a portal, is created by a Portal account/developer or by an administrator on their behalf, and is visible on the portal. |
| Internal | A first-party application created by an administrator for the organization's own use. It belongs to no portal and is never listed on a portal surface: a Portal user cannot see it, create it, or edit it, and it cannot be promoted to production. |
The type is chosen while the application is being created and cannot be changed afterwards. An application whose type is not shown is a Portal application created before this distinction existed.
The application quota defined for an organization applies to Portal applications only; Internal applications are not counted against it. An organization that already holds internal applications therefore has more room for new portal applications than it did before this version.
Application List
The list shows the application name, its type, the linked account/developer, organization, creation date, and reference id. The Type: All filter above the list narrows the list to a single type; while nothing is selected, both types are listed. Clicking an application in the list opens its detail page.
Which applications the list contains depends on where it was opened from. Opened from a project's Identity → Applications menu, it lists only the applications of the active project (an application that carries no project is shown to every project). Opened from Administration → Identity → Applications, it lists every application across projects, and a Project column shows where each one belongs.
Creating / Editing an Application
Use the Create button above the list to create a new application. Use the Edit option in the row actions menu to edit an existing application.
| Field | Description |
|---|---|
| Name | The name of the application. Required. |
| Type | Portal or Internal. It can be chosen only while the application is being created; on an existing application it is shown read-only. See Application Types. |
| Application Key | A permanent, readable identity generated by the server when the application is created. It cannot be edited, and it is shown with a copy button on the edit and detail screens. |
| Reference Id | A reference value used to uniquely identify the application in external systems. It is generated automatically when the application is created and can be changed manually if needed. Required. |
| Description | A description of the application. |
| Account | The Portal account/developer the application belongs to. Required. |
| Do not log traffic | Stops the API traffic of every consumer bound to this application from being written to the traffic log connectors. Off by default. See Turning Traffic Logging Off for an Application. |
The application key identifies the application permanently, so it is never carried over to another record: an application created by copying or by importing a package receives a new key of its own. The same rule applies to the credential consumer key.
The Edit screen also shows the same read-only Details and Linked Resources panels as the application's detail view — organization, project, creation date, type, traffic-log status, application key, reference id, and the Consumers/API Products counts — so switching from the detail view to Edit does not lose that context. The three fields you edit here (name, description, do-not-log-traffic) are shown only as live controls below, not repeated in the read-only panel.
Application Detail
The application detail page has four tabs: Overview, API Clients, Access and Metadata.
Overview
This tab shows the application's name, type, application key, reference id, linked account/developer, organization, and creation date. It also lists the API keys defined for the application: the key itself, its enabled/disabled state, its creation date, and its expiration date (if any). From the edit screen you can generate a new API key for the application or revoke an existing one.
The view opened from the Portal menu additionally lists the API Products the application is subscribed to, along with their plan/approval status. This information is not shown in the view opened from the Identity menu.
API Clients
An application can hold its own API clients: machine identities with their own client id and their own versioned client secrets, obtaining tokens on behalf of the application rather than on behalf of a single credential beneath it. The tab works exactly like the one on the credential screen — create a draft, issue a client secret, then activate. For the client secret ceremony, the reveal rules and the authorization modes, see Credentials.
A client owned by an application starts at Deny all. It reaches nothing until a target is named on its Authorization sub-tab — and only a target the application itself already holds on the Access tab below. This can surprise an operator: since live traffic is open to API clients (see below), a freshly created application-owned client fails every request until this is done, even when the application itself already holds broad access.
An API client can obtain a token and use it to call an API Proxy directly, governed by Authorization of an API Client and Owner and Client Lifecycle. The second of those applies to the application itself, too: suspending the application (see Deleting an Application) immediately rejects both live traffic and new token requests for every API client it owns, in addition to its own credentials — the client's own state and authorization are irrelevant while its owner is suspended. The same holds one level up: while the organization the application belongs to (or any organization above it) is suspended, every API client under the application is rejected the same way.
Access
An application owns its access grants. They are not derived from the access control lists of the credentials beneath it: a newly created application reaches nothing at all until a grant is written on this tab.
Each row names a target — an API Proxy, an API Proxy group, an API Product, or an API Proxy narrowed to a single environment — and carries a validity window, a status and a source.
- The validity window is half-open: the start moment is included, the end moment is not. A grant that ends at the moment its successor begins therefore never overlaps with it. Leave a field empty for an open end.
- A grant is created as a draft and put into force with Activate. Its shape is validated again at that moment, because a draft may have been changed meanwhile.
- Ending a grant does not delete the row. It is marked as ended and stays as part of the history, so the answer to "what could this application reach last month" is kept.
When a grant is ended, an API client restriction that pointed at that target is left as it is rather than being removed with it; the tab reports how many such restrictions there are. A runtime decision is the intersection of the owner's grants and the client's restriction, so an orphaned restriction grants nothing on its own — whereas deleting data could not be undone.
Metadata
This tab lets you define application-specific key-value entries. Complex data types are not supported; only plain text values can be entered.
| Field | Description |
|---|---|
| Key | The key of the metadata entry. Required, and unique within the application; the same key cannot be used more than once. |
| Value | The value corresponding to the key. |
| Secret | When enabled, the value is stored encrypted and masked in lists. |
Use the + button at the start of a row to add a new entry, and the delete button at the end of a row to remove one. Changes are applied with the Save button.
Turning Traffic Logging Off for an Application
Some customers ask, on privacy or data-protection grounds, that their API traffic not be retained. Do not log traffic answers that request at the application level: while it is on, the traffic of every consumer bound to the application — both classic consumers and API Clients — is sent to no traffic log connector at all (Elasticsearch, Kafka, Syslog, Database and the rest).
Applications with the switch on carry a Traffic log off badge in the application list, so a silenced customer is visible without opening each record.
The scope is deliberately narrow. Turning this on does not stop:
- Trace records and OpenTelemetry spans — the operational trail used to diagnose an incident
- Prometheus metrics — request counts and durations, which carry no message content
- Security and access events — the audit trail behind quota, anomaly and security investigations
- Requests that failed authentication — a request is only silenced once the gateway has actually verified the identity presented. A caller who sends a silenced consumer's username with a wrong password, an invalid API key or a rejected token is not that consumer as far as this switch is concerned, and the blocked request is written to the traffic log connectors as usual. Failed-authentication traffic is exactly what a later investigation needs, so it is never something an unverified caller can suppress.
A privacy preference must not be able to erase a security or audit trail, which is why those lanes stay open. When an installation genuinely needs zero retention, the right instrument is the No Persist data retention profile, not this switch.
This switch is set from the Manager screens (or through APIops) by someone with administrative rights. It is deliberately not offered on the API Portal: a portal customer editing their own record or their own application cannot turn it on or off, and a value sent in a portal request body is ignored rather than applied. The reason is that switching it on removes a customer's traffic from the SIEM/Elasticsearch/Kafka feeds security and fraud monitoring rely on — that has to stay an operator's decision.
The same switch exists on individual consumers (Credentials). The two are independent and combine as either one is enough: a consumer is silenced if it has been switched off itself or its application has.
Saving is enough. The application's consumers and API Clients are redeployed to the running environments automatically, so no manual redeploy is required and the change applies to the next request.
Deleting an Application
Only an application in the Test promotion state can be permanently deleted, and even then only while it holds no credentials, access grants, product subscriptions or API clients not yet revoked. An application that still carries any of those is refused the same way a promoted application is — resolve or remove the relationship first (for an API client, revoke it), or archive the application instead. A Test application that truly has nothing attached is deleted along with its (empty) API key and subscription records. Deletion is confirmed with a confirmation dialog.
An application whose promotion is Pending, whose promotion request was Rejected, or that is already in Production carries production access or an open promotion decision, so it can no longer be deleted. Its Delete action is not offered in the list; use Suspend to stop its traffic while keeping every record.
The same two checks — promotion state, then whether anything is still attached — apply to the decision on a deletion request coming from the portal. Approve as Archive — which retires the application while preserving its consumption and audit history — is offered first and needs no extra confirmation; Approve as Delete is offered only where the delete can actually succeed; Reject is always available. Submitting a deletion request only disables the application's credentials, it does not remove them, so approving as a hard delete still requires the same clean slate as deleting the application directly.
Deleting an entire portal from Danger Zone applies these exact same checks to every application it contains — see Portal Deletion for what that means for the portal as a whole.
An application whose promotion request was rejected cannot be deleted either. A rejected request can still be completed and resubmitted by the consumer, so the application and its history are kept. If it will no longer be used, archive or suspend it.
A Test application that still had credentials, access grants or subscriptions used to be deleted along with them. That is no longer the case: the relationship has to be resolved, or the application archived, before a delete is offered. A pending deletion request that used to be approved as a hard delete may now need to be approved as an archive instead.
The rule is enforced on the server, not only in the interface. A deletion sent directly to the Management API for a promoted application, or for a Test application that still has something attached, is refused the same way the manager interface refuses it, and the application is left untouched.
If a delete for the same application is already being processed, a second attempt is refused with an HTTP 409 response until the first one finishes. See Concurrent Deletion if this persists long after nothing is actually running.
Creating, editing, and deleting applications is available to roles with system administrator or portal management/developer authority.
Transferring an Application to Another Organization
An application can be moved to a different organization of the same project with the Transfer button among the header actions of the application's detail view, which opens a dialog to pick the target organization. The move carries everything the application owns along with it: the consumers the application owns — together with their own API clients, access control entries and tokens — and the application's own API clients and product subscriptions are all re-linked to the new organization in the same operation, and the application's API clients are re-pushed so the change takes effect immediately. Quota usage figures are not rewritten by the transfer itself — they correct themselves on their next regular synchronization.
If the target organization is suspended, traffic for the application and the consumers it owns stops immediately after the transfer. Resume the target organization to let traffic flow again.
The transfer is refused, and nothing is changed, when:
- the application is being deleted or is already archived;
- a delete of the application, or of the organization it is leaving or joining, is currently in progress;
- the target organization does not resolve, does not belong to the same project as the application, or has been merged into another organization;
- the target organization is the one the application is already in.
The rule is enforced on the server, not only in the interface. A transfer request sent directly to the Management API is refused the same way for an application being deleted or archived, an unresolved or cross-project target, or while a delete is in progress on the application or on either organization.
Audit Records
Every change made to an application is written to the audit log. An application that carries a project is now audited under that project, so its records are listed when the audit screen is filtered by the project it belongs to. An application created from the portal is given the portal's project when that portal is bound to exactly one project; when the portal covers several projects — or none — no project is guessed and the application keeps being audited in the shared (admin) scope, as before.
Audit records written before this version are not rewritten. An application whose records used to be listed in the shared (admin) scope keeps its earlier history there, while records written from this version on appear under the application's own project. No data is lost — the history of such an application is simply read from two scopes.
Related Pages
For the credentials granted access to the application and their API Proxy-based access settings, see Access Control. For the credential records of the account the application belongs to, see Credentials.