My APIs
Develop, manage, test, and expose your own APIs in the API Composer
The My APIs workspace (also called the API Composer) is where you develop, organize, and expose your own APIs inside FlowGenX. While API Import is focused on bringing an external specification into the platform, My APIs is the collection view and authoring surface for everything you build and manage afterwards.
Develop and expose your own APIs
Create, import, test, and manage your API collection in one place
My APIs vs. API Import
These are two consecutive stages of the same feature, not duplicates:
API Import
Bring an external OpenAPI 3.0, Swagger 2.0, or Postman specification into the platform.
My APIs
Manage the whole collection, author new APIs by hand, test endpoints, and expose them as agent tools.
The My APIs Workspace
Open Integration Studio → My APIs to see every API in the current tenant and environment. Each API is shown as a card (or as a row in List View) with its name, description, source type, endpoint count, base path, and environment.
The toolbar provides:
- New API — author an API by hand (see Creating a New API).
- Import — bring in an OpenAPI/Swagger spec via the import modal.
- Cards / List — toggle between the card grid and a compact list.
- Refresh — reload the collection.
- Search — filter your APIs by name or description.
- Filters — narrow the collection by Environment and Runtime Instance, or open Advanced Filters for more options. Any active filters can be cleared in one click.
Tenant & environment scoped: the list shows APIs for your selected tenant and environment. Select a tenant and create at least one environment before using My APIs.
API Source Types
Every API carries a source-type badge that tells you how it was created:
| Badge | Meaning |
|---|---|
| Imported | Created by importing an OpenAPI/Swagger/Postman specification. |
| Manual | Defined by hand in the New API form. |
| Cloned | Duplicated from an existing API in your collection. |
| Designer | Built visually in the API designer. |
| Draft | A work in progress that has not been finalized yet. |
Creating a New API
Click New API to open the form and define an API from scratch:
Basic Information
Give the API a Name, select the target Environment, and add a Description of its purpose and functionality.
Configuration
Choose the Source Type and set the Base Path (for example /api/v1) that all endpoints are relative to.
Tags
Add tags to keep large collections organized and easy to filter.
Prefer to start from an existing definition? Use Import instead — see API Import for the OpenAPI/Swagger/Postman flow. Imported APIs land in this same collection with the Imported badge.
Defining Endpoints
Open an API to manage its endpoints. Endpoints are listed in a sidebar grouped by HTTP method (GET, POST, PUT, …), each method color-coded and collapsible.
When you add or edit an endpoint, you define:
| Field | Description |
|---|---|
| Method | The HTTP verb — GET, POST, PUT, PATCH, DELETE, etc. |
| Path | Must start with / (for example /users/{id}). It is appended to the API's Base Path to form the full request URL. |
| Path Variables | Values for the {...} placeholders in the path. |
| Query Parameters | Key/value pairs appended to the URL. |
| Headers | Request headers to send. |
| Body | The request payload — shown for POST, PUT, and PATCH. |
Authentication
Each endpoint can carry its own authentication, applied automatically whenever you test or expose it. Supported schemes include API Key, Bearer Token, Basic Auth, Digest, Hawk, OAuth 2.0, and Custom Headers — the same options available in Auth Configs. Store credentials in Auth Configs rather than hardcoding them in the endpoint definition.
Managing Your APIs
Each API card exposes the actions you need to maintain it:
Testing Endpoints
Click Test on an API to open the endpoint test workbench (similar to Postman):
- Pick an endpoint from the method-grouped sidebar
- Open one or more endpoints as tabs and work across them — unsaved changes are flagged per tab
- Fill in path variables, query parameters, headers, and body
- Send the request and inspect the live response — status code, headers, body, and timing
Any authentication configured on the endpoint is applied to the request automatically.
Execution History
The workbench keeps a history of your test runs. Each entry records its status — Completed, Failed, Pending, or Processing — and you can filter the history by status and by time window (for example, the last 24 hours) to quickly find a specific run.
Exposing APIs as Agent Tools
Once an API is defined and tested, the final step is to expose it so AI agents can call it. FlowGenX turns your API endpoints into MCP tools — each endpoint becomes a callable tool an agent can invoke inside a workflow, with no extra glue code.
From API to agent tool
Your tested endpoints become MCP tools that agents can call directly
Select an API from your collection
Generate MCP tools from its endpoints
Attach the tools to an agent in a workflow
The endpoint metadata you already defined — method, path, parameters, and authentication — carries over automatically, so an agent calls each endpoint exactly the way you tested it. See OpenAPI Spec to MCP Servers for the full conversion flow, and MCP Tools for using the generated tools inside a workflow.
Test first, expose second. Verify each endpoint in the test workbench before generating tools — an agent will call the endpoint exactly as configured, so a working test means a working tool.
Best Practices
Tips
- Use environments: keep separate definitions per environment so you can promote from Staging to Production safely.
- Tag consistently: tags make a growing collection searchable and easy to group.
- Secure credentials: never hardcode API keys in a definition — manage them with Auth Configs.
- Test before exposing: verify endpoints in the testing interface before turning them into agent tools.