# API Management API Management in Frends is the central place for defining, managing, and deploying APIs across your Tenant. In Frends, an API is built on an OpenAPI specification and fulfilled either by Processes or by passthrough configuration. This reference article covers how APIs work architecturally in Frends, explains the versioning model, and then walks through every element of the API Management view in the order it appears in the interface.

API Management view in Frends.

## How APIs work in Frends APIs in Frends are defined using the OpenAPI specification and deployed to Agent Groups. Each API contains one or more operations, and each operation is fulfilled either by a dedicated Process or by a passthrough configuration that forwards the request to another backend system. When a caller makes an HTTP request to an API endpoint, the Agent handling that Agent Group receives the request, matches it to the correct API operation, and either triggers the linked Process or forwards it to the passthrough target. APIs can only be created in a Development Environment and Agent Group, but once created they can be deployed to any other Agent Group, such as Test or Production. The Server URL defined in the OpenAPI specification forms the base path of the API. This path is appended after the Agent Group's base URL, so the full address a caller uses depends on which Agent Group the API has been deployed to. Because of this, the same API definition can be live on multiple Agent Groups at the same time, each running independently. ### APIs and Processes The connection between an API operation and a Process is made through an API Trigger. A Process linked to an API endpoint must have exactly one API Trigger, and a single Process cannot be linked to more than one endpoint at the same time. If the same integration logic is needed across multiple endpoints, that logic should be placed in a Subprocess and reused from separate endpoint-specific Processes. When a Process is linked to an API endpoint, incoming HTTP requests that match the operation's method and path are routed to that Process. The API Trigger provides the request data — such as path parameters, query parameters, headers, and body — as variables that the Process can use directly. The response is returned through a Return shape configured to match one of the response definitions in the OpenAPI specification. ### APIs and Policies Authentication, throttling, and access control for APIs in Frends are managed through API Policies rather than through the OpenAPI specification itself. The `securitySchemes` section in an OpenAPI specification is supported mostly for documentation purposes, but the effective runtime security is always determined by the API Policy applied to the API. API Policies support API key authentication, OAuth bearer tokens, and private application tokens, and can target specific operations or apply broadly using wildcard patterns. API Policies are managed separately from the API definition, meaning security configuration can be updated without modifying the OpenAPI specification or redeploying the API. ## API versioning Versioning in Frends follows semantic versioning in the format `major.minor.patch`. For APIs, the version is managed automatically by Frends based on specific lifecycle events rather than requiring manual version management. The patch version increments automatically with each change saved to the API specification. This means that every time the OpenAPI definition is edited and saved, Frends records a new patch version of the API. The major version increments each time the API is deployed to an Agent Group. This separation means that you can iterate on the API specification freely during development, and a new deployable major version is only created when you explicitly deploy. Published API versions are immutable. Once a version has been deployed, it cannot be changed — only a new deployment creates a new version. This makes it possible to roll back to a previous deployed version if needed, and to run multiple versions of the same API in parallel across different Agent Groups. URI-based versioning, such as `/api/users/v1` and `/api/users/v2`, is a common pattern for exposing multiple live versions to callers. Process versions follow the same semantic versioning model, but with the distinction that minor and major versions can also be changed manually by the developer to reflect meaningful milestones or release boundaries. API versions are managed fully automatically by Frends. ## API Management view The API Management view is the central management page for APIs in Frends. The page is split into two areas: the left side holds the API list and a search field, and the right side shows the details, actions, and methods for the currently selected API. At the top of the view, a selector controls the active Environment and Agent Group, which determines which APIs are visible and which Agent Group is targeted when deploying or opening the API Specification UI. ### API list The API list shows all APIs available in the selected context. Each entry displays the API name, its current version, and a short description from the OpenAPI specification. Selecting an entry loads its details into the right-hand panel. A search field above the list filters entries by API name or path, which is useful when the Agent Group contains many APIs. The `Create new` button above the list starts the API creation flow. APIs are defined using an OpenAPI specification — primarily version `3.0.4`, with `2.0` supported for legacy use. The key values Frends reads from the specification are `title`, `description`, `version`, `server URL`, and `paths`. The `server URL` defines the base path of the API, must begin with `/api/`, and must be unique across the Agent Group, with the `paths` adding the endpoint and Process specific path after the API base URL. Agent Group defines the actual server URL, where the API is published at.

API specification editor view.

### API details panel The details panel shows the selected API's title, version, base path, and description, all sourced from the OpenAPI specification. Below those, `Modifier` and `Modified` fields show who last edited the API and when. These are read-only metadata fields maintained automatically by Frends. The panel is the main working area for an API. It is where you review endpoint coverage, check whether operations are linked to Processes or configured as passthrough, and access all management actions for the API. ## Action buttons The right side of the API details panel contains actions for managing and operating the selected API. These actions provide access to deployment, monitoring, editing, specification-based testing, and passthrough configuration. ### Deploy The `Deploy` button starts API deployment. Deploying an API creates a new API version, shows a preview of the API specification and endpoints, and deploys the linked Processes together with the API. This is the preferred way to move the API and its connected integrations to another Environment or Agent Group. The deployment flow is similar to Process deployment. You choose the target Agent Group and the Process versions to include, then deploy and activate the linked Triggers. Linked Processes should not be deployed separately from the API, because this can create warnings in API Management that need to be resolved by redeploying the API. ### View Monitoring The `View Monitoring` button opens API Monitoring for the selected API. API Monitoring shows incoming connections to the Tenant and their outcomes, and allows filtering by values such as API operation, HTTP status code, and method. This action is useful when verifying whether callers reached the API, whether authentication succeeded, and what responses were returned. Monitoring also includes requests that did not result in successful execution. ### Edit The `Edit` button opens the API specification editor for the selected API. Frends uses the OpenAPI specification as the source of truth for the API definition, so editing the API means editing that specification. \[Placeholder for screenshot: OpenAPI specification editor opened from the Edit action.] ### Delete The delete icon removes the selected API from API Management. In the screenshot, this action is represented by a trash icon next to the edit controls. Before removing an API, make sure the linked integrations are no longer needed, because endpoint mappings and related runtime access depend on the API definition being present. The provided sources describe the icon visually in the view, but do not describe the deletion flow in more detail. When deleting the API, you are given the option to also delete the linked Processes. If not deleted, the Processes can stay active and functional even after the API specification has been deleted for them, but modifying them will require recreating the API Trigger as it will no longer have the connection to the specified API.

Error message about existing API Processes without API definition.

### API Specification UI The `API Specification UI` button opens the interactive documentation for the API. Frends automatically exposes documentation for APIs created in Frends through a Swagger UI-based page hosted on the Agent URL. This UI allows users to inspect operations, authenticate where needed, and execute test calls directly against the API. If the button is inactive, the linked Processes are not activated in the selected Agent Group. When available, the UI targets the selected Agent Group and can be used to call the endpoint after any required authorization has been provided. #### Locking the API Specification UI The lock icon next to the `API Specification UI` button controls whether the UI is publicly accessible. By default, the API Specification UI is open. When locked, it requires an API Key defined through an API Policy. To secure the access to your API Specification UI, follow this guide: [Securing the API Specification UI](/guides/api-management/securing-the-api-specification-ui.md). ### Create / Modify Passthrough API The `Create` or `Modify Passthrough API` button opens passthrough configuration for the selected API. Passthrough APIs are used when Frends should forward incoming requests to another backend system without Process-based integration logic. For a full reference on passthrough configuration, see the Passthrough API reference documentation. ## Methods section The `Methods` section lists the operations defined by the selected API specification. Each entry corresponds to an HTTP method and path combination from the OpenAPI `paths` section, and together they represent the full surface of the API as it is defined in the specification. Each row shows the HTTP verb — such as `GET` or `POST` — followed by the operation path relative to the API base URL, such as `/users` or `/users/{id}`. An operation summary or description from the specification is shown beneath the path. The HTTP verb labels are color-coded in the UI to help distinguish operation types at a glance. Each operation row also shows its current integration status. If a Process has already been linked to the operation, the row displays the linked Process. If no Process exists yet, the row shows a `Create new Process` button, which opens the Process Editor with a preconfigured template — including an API Trigger for that endpoint and Return shapes matching the responses defined in the specification. If the operation is handled through passthrough configuration rather than a Process, the row shows a `Passthrough API` indicator instead. Method rows include per-operation action icons on the right side for additional operation-level controls. ## How to use the view The usual flow in API Management starts with creating or selecting an API, then defining or reviewing its OpenAPI specification. After that, each operation is either linked to a Process or configured as passthrough, depending on whether Frends should execute integration logic or only forward the request. Once the operations are ready, the API is deployed from the same view. Deployment moves the API and its linked Processes to the target Agent Group and can activate the required Triggers. After deployment, the API can be tested through the API Specification UI and observed through API Monitoring. Access control and runtime logging are then configured through API Policies. ## Field and value details The fields and values visible in the view are a combination of API specification values, system metadata, and runtime management controls. ### API specification-based values The following values are derived from the OpenAPI definition and shown in the view or related UI: `Title` is the display name of the API. `Description` is the displayed summary text for the API. `Version` is maintained by Frends and follows semantic versioning behavior for API changes and deployment. `Server URL` defines the API base path after actual server URL from Agent Group, and must start with `/api/`. `Paths` define the methods and operations shown in the methods section. `securitySchemes` may be present in the specification, but API Policies in Frends largely determine the effective authentication behavior for runtime access. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.frends.com/reference/api-management/api-management.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.