API Collections group related endpoints under a shared base path and version, forming the top-level unit of a published API in the API Manager.
Overview
A collection is the container that holds a logical API together. It sets the base path every endpoint inside it inherits, carries its own version label, and lets you apply policies, telemetry, and logging settings once for the whole group. Clients are granted access at the collection level, and an OpenAPI spec can be exported for the entire collection. Think of a collection as one published API and its endpoints as the individual operations.
Creating a Collection
Navigate to API Manager › Collections and create a new collection. The fields to configure are:
Name — a display name for the API (for example, "Orders API").
Path — the base URL path all endpoints in this collection share (for example, /orders). Must be unique within your project.
Description — what the API is for, shown to clients and in the OpenAPI export.
API version — a version label (for example, v1). Must be unique within the same base path.
Include version in path — when on, the version appears in the URL (so /v1/orders/...), letting multiple versions run simultaneously at distinct URLs.
Policies — collection-wide governance rules applied to every endpoint inside it.
API URL Structure
A managed endpoint's public URL follows this pattern:
https://<your-domain>/<collection-path>/<endpoint-path>
For example, https://acme.unifyapps.com/orders/123. When Include version in path is on, the version sits between domain and collection path — for example https://acme.unifyapps.com/v1/orders/123. Path variables in an endpoint (like {"{id}"}) are filled by the caller. This is the address you give to consumers of the API.
Versioning
Each collection carries an API version label. To run multiple versions at the same time, keep the current collection live and publish a new one with the same base path but a different version (and Include version in path enabled), so callers choose /v1/ or /v2/ explicitly. Callers on the older version continue working without changes until they choose to migrate. For gradual rollouts of a change within a version, use an endpoint's canary deployment settings instead.
OpenAPI Export
You can export an OpenAPI specification for a single endpoint, a whole collection, or all collections at once. The exported spec describes paths, methods, parameters, and request/response schemas — ready to load into Swagger UI, Postman, or any other OpenAPI-compatible tool. Exporting is the fastest way to hand a consumer a machine-readable contract without writing documentation by hand.
Collection Settings
Beyond endpoints, a collection holds settings that apply across all its endpoints:
Policies — governance rules that every endpoint inherits (individual endpoints can still add their own).
Telemetry — metric configurations (counters and timers) that control what gets measured and fed to the Insights dashboard.
Traceability — custom trace headers and workflow logging defaults for all endpoints in the collection.
Activity — a history of changes made to the collection.
Clients — the list of clients whose access profiles include this collection.
Notes
Name collections after the domain they represent ("Orders API", "Customer API") — consumers see this name in the OpenAPI export.
Turn on Include version in path from the start if you anticipate breaking changes; retrofitting versioning into an existing path is disruptive.
Set collection-level policies for broad baselines (a default rate limit, CORS), then tighten per endpoint.
Export the OpenAPI spec as the official contract to share with consuming teams — it reflects the schemas you define on each endpoint.
A collection's base path must be unique in the project; plan paths as you would a URL namespace.