Manage Applications
Applications are containers that developers create to group subscriptions and credentials. Each application belongs to a single developer (or, in organization mode, an active organization context).
Application management is exposed by the standalone Developer Portal backend rather than the Dashboard / Provider Portal Admin API. The default Developer Portal frontend reads and writes applications through this backend, and the same endpoints can be called directly.
Application Structure
Each application contains:
| Component | Description |
|---|---|
| Subscriptions | Links to API products that grant the application access to consume APIs. |
| Credentials | Authentication tokens (API keys, basic auth credentials, OAuth clients) used to authenticate API requests through the gateway. |
| Labels | Optional key-value pairs for categorization and filtering. |
Application Lifecycle
Applications follow this lifecycle:
- Created by a developer in the Developer Portal.
- Active while the developer uses it to subscribe to API products and make API calls.
- Deleted by the developer or cascaded when the developer account is deleted.
Deleting an application also deletes all its credentials and cancels all its subscriptions. For OAuth (DCR) credentials, the registered clients are also removed from the identity provider.
Manage Applications from the Developer Portal UI
End-user workflows for creating, viewing, and deleting applications are documented in the developer-facing guides:
Manage Applications Programmatically
Application endpoints live on the standalone Developer Portal backend (default :4321), not the Dashboard Admin API on :7443. They authenticate with a portal token (a7prt-…) issued from Provider Portal > Portal Settings > Tokens and an X-Portal-Developer-ID header that identifies the active developer or organization context.
All operations on applications are documented in the Developer Portal API reference, including:
| Operation | Endpoint |
|---|---|
| Create an application | POST /api/applications |
| List applications | GET /api/applications |
| Get an application | GET /api/applications/{application_id} |
| Update an application | PUT /api/applications/{application_id} |
| Delete an application | DELETE /api/applications/{application_id} |
| Get API call statistics | GET /api/applications/api_calls |
The reference page lists the full parameter, request body, and response schemas. The /api/applications/api_calls endpoint, in particular, accepts repeatable filters (application_id, api_product_id, credential_id) and required start_at / end_at Unix-second timestamps.
For JavaScript and TypeScript integrations, the @api7/portal-sdk package generates a typed client from the same OpenAPI specification. This reference page is pinned to the spec shipped with portal-sdk@1.1.0; install that exact version (npm install @api7/portal-sdk@1.1.0) to stay aligned with the contract documented here, or upgrade both together when a newer release is supported.
The backend endpoints are fixed and owned by the API7 control plane. How a portal frontend obtains the portal token and resolves the active developer context can vary by implementation; the endpoints themselves do not.