> ## Documentation Index
> Fetch the complete documentation index at: https://tyk.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Designing Your API Portfolio

> Use API Categories, API Templates and API Fragments to keep a growing portfolio of APIs consistent, and to share ownership between a platform team and API teams.

## Introduction

When you have a few APIs, you can configure each one by hand. As the number of APIs grows, this gets harder:

* Every API needs the same baseline, such as authentication, upstream TLS settings and logging. Configuring it by hand for each API takes time and causes mistakes.
* Copies of the same configuration drift apart, so APIs that should behave the same way don't.
* A change to a shared standard, such as a new allowed origin or a stricter rate limit, means editing many APIs. It is also hard to know which APIs to change.
* Different people are responsible for different parts of an API. A platform team owns the standards, and API teams own their APIs.

Tyk Dashboard gives you three tools to manage this. You can use them separately or together:

| Tool | What it does | When it applies |
| :- | :- | :- |
| [API Categories](https://tyk.io/docs/platform-management/api-categories.md) | Groups APIs, for example by team, domain or environment | While the API exists |
| [API Templates](https://tyk.io/docs/platform-management/api-templates.md) | Gives a new API a standard starting point | Once, when you create the API |
| [API Fragments](https://tyk.io/docs/platform-management/api-fragments.md) | Shares configuration that stays linked to every API that uses it | While the API references the Fragment |

## Choosing Between Templates and Fragments

Templates and Fragments both help you reuse configuration. The difference is what happens after you create the API:

* Tyk Dashboard **copies** a Template into a new API. After that, the API and the Template are independent. Use a Template for configuration that each API starts with but can then change, such as default endpoints or a cache configuration that API teams tune.
* An API keeps a **reference** to a Fragment. When you change the Fragment, every API that references it changes too. Use a Fragment for configuration that must stay the same across APIs, such as a security standard.

You get the most value when you combine them. A Template can contain Fragment references. When an API team creates an API from the Template, the new API starts with the standard configuration from the Template. It also stays linked to the Fragments, for the configuration that must not drift. This gives API teams a quick, standard way to create APIs, and gives the platform team one place to change the shared configuration.

## Sharing Ownership Between Teams

Templates and Fragments let you split the responsibility for an API between teams:

* The **platform team** owns the Templates and Fragments. It decides the standard configuration, and changes it in one place.
* **API teams** own their APIs. They create APIs from the Templates, and change the parts of their APIs that the Fragments don't set. In the API Designer, settings from a Fragment show the **Shared configuration** badge, and API teams can't change them in the API.

Use [user permissions](https://tyk.io/docs/platform-management/user-permissions.md) to enforce this split. Give the platform team write access to the `api_assets` permission, which controls Templates and Fragments. Give API teams write access to the `apis` permission, and read access to `api_assets` so that they can use the Templates. Before you give write access to `api_assets`, read [Control Access to Fragments](https://tyk.io/docs/platform-management/api-fragments.md#control-access-to-fragments).

Use [API ownership](https://tyk.io/docs/platform-management/api-ownership.md) to give each API team access to only its own APIs, and [API Categories](https://tyk.io/docs/platform-management/api-categories.md) to group them.

## Designing Standards In and Checking for Them

Templates and Fragments build your standards into APIs when you create them. [Tyk Governance](https://tyk.io/docs/tyk-governance/overview.md), a licensed capability of Tyk Dashboard, checks APIs against your standards, and reports the APIs that don't meet them. The two work together:

* Use Templates and Fragments so that new APIs meet your standards from the start.
* Use Governance rulesets to find existing APIs that don't meet your standards, and to catch changes that break them.

Tyk Governance evaluates each API with its Fragment references resolved, so configuration that comes from a Fragment counts towards compliance. When you change a Fragment, Tyk Governance evaluates the APIs that reference it again. You can also use API Categories to choose which APIs a ruleset applies to. See [Scoping Rulesets](https://tyk.io/docs/tyk-governance/scoping-rulesets.md).