# Server API for plugins

> Source: https://docs.strapi.io/cms/plugins-development/server-api

The Server API defines what a plugin registers, exposes, and executes on the Strapi server. It covers lifecycle hooks, routes, controllers, services, policies, middlewares, and configuration. Use the entry file to declare what the plugin contributes, then navigate to the dedicated pages below for each capability.

A Strapi plugin can interact with both the back end and the front end of a Strapi application. The Server API covers the back-end part: it defines what the plugin registers, exposes, and executes on the Strapi server. The server part is defined in the entry file, which exports an object (or a function returning an object). That object describes what the plugin contributes to the server.

For more information on how plugins can customize the admin panel UI, see [Admin Panel API](/cms/plugins-development/admin-panel-api).

:::prerequisites
Before diving deeper into the concepts on this page, please ensure you [created a Strapi plugin](/cms/plugins-development/create-a-plugin).
:::

## Entry file

The entry file for the Server API is `[plugin-name]/server/src/index.js|ts`. This file exports the required interface, with the following parameters available:

| Parameter type | Available parameters |
| --- | --- |
| Lifecycle functions | [`register()`](/cms/plugins-development/server-lifecycle#register), [`bootstrap()`](/cms/plugins-development/server-lifecycle#bootstrap), [`destroy()`](/cms/plugins-development/server-lifecycle#destroy) |
| Configuration | [`config`](/cms/plugins-development/server-configuration) object |
| Backend customizations | [`contentTypes`](/cms/plugins-development/server-content-types), [`routes`](/cms/plugins-development/server-routes), [`controllers`](/cms/plugins-development/server-controllers-services#controllers), [`services`](/cms/plugins-development/server-controllers-services#services), [`policies`](/cms/plugins-development/server-policies-middlewares#policies), [`middlewares`](/cms/plugins-development/server-policies-middlewares#middlewares) |

A minimal entry file looks like this:

```js title="/src/plugins/my-plugin/server/src/index.js"
'use strict';

const register = require('./register');
const bootstrap = require('./bootstrap');
const destroy = require('./destroy');
const config = require('./config');
const contentTypes = require('./content-types');
const routes = require('./routes');
const controllers = require('./controllers');
const services = require('./services');
const policies = require('./policies');
const middlewares = require('./middlewares');

module.exports = () => ({
  register,
  bootstrap,
  destroy,
  config,
  contentTypes,
  routes,
  controllers,
  services,
  policies,
  middlewares,
});
```
```ts title="/src/plugins/my-plugin/server/src/index.ts"

  register,
  bootstrap,
  destroy,
  config,
  contentTypes,
  routes,
  controllers,
  services,
  policies,
  middlewares,
});
```

All server code can technically live in the single entry file, but splitting each concern into its own folder, as generated by the Plugin SDK, is strongly recommended. The examples in this documentation follow that structure.

:::note Notes
* The entry file accepts either an object literal or a function that returns the same object shape. When the function form is used, Strapi calls it with `{ env }` (not `{ strapi }`) while loading the plugin module.
* `config` is a configuration object, not an executable lifecycle hook. Unlike `register()`, `bootstrap()`, or `destroy()`, it is not called as a function during the plugin lifecycle. It is loaded at startup and used to set defaults and validate user configuration. See [server lifecycle](/cms/plugins-development/server-lifecycle) for more information.
:::

## Available actions

The Server API lets a plugin take advantage of several building blocks to define its server-side behavior.

Use the following table to find which capability matches your goal:

| Goal | Parameter to use | When it runs |
| --- | --- | --- |
| Run code before the server starts | [`register()`](/cms/plugins-development/server-lifecycle#register) | Before database and routing initialization |
| Run code after all plugins are loaded | [`bootstrap()`](/cms/plugins-development/server-lifecycle#bootstrap) | After database, routes, and permissions are initialized |
| Clean up resources on shutdown | [`destroy()`](/cms/plugins-development/server-lifecycle#destroy) | On shutdown |
| Define plugin options with defaults and validation | [`config`](/cms/plugins-development/server-configuration) | Loaded at startup |
| Declare plugin content-types | [`contentTypes`](/cms/plugins-development/server-content-types) | Loaded at startup |
| Expose HTTP endpoints | [`routes`](/cms/plugins-development/server-routes) | Loaded at startup |
| Handle HTTP requests | [`controllers`](/cms/plugins-development/server-controllers-services#controllers) | Called per request |
| Implement business logic | [`services`](/cms/plugins-development/server-controllers-services#services) | Called from controllers or lifecycle hooks |
| Enforce access rules on routes | [`policies`](/cms/plugins-development/server-policies-middlewares#policies) | Evaluated per request, before controller |
| Intercept and modify request/response flow | [`middlewares`](/cms/plugins-development/server-policies-middlewares#middlewares) | Attached in `register()` or referenced in route config |
| Access plugin features at runtime | [Getters](/cms/plugins-development/server-getters-usage) | Any lifecycle or request handler |

<br/>

The following cards link directly to each dedicated page:

- [Lifecycle](/cms/plugins-development/server-lifecycle): Control when plugin server logic runs with register, bootstrap, and destroy hooks.
- [Configuration](/cms/plugins-development/server-configuration): Declare default plugin options and validate user-provided config from config/plugins.
- [Content-types](/cms/plugins-development/server-content-types): Declare plugin content-types and access them at runtime through the Document Service API.
- [Routes](/cms/plugins-development/server-routes): Expose plugin endpoints as Content API or admin routes with full control over auth and policies.
- [Controllers & services](/cms/plugins-development/server-controllers-services): Handle requests in controllers and organize reusable business logic in services.
- [Policies & middlewares](/cms/plugins-development/server-policies-middlewares): Enforce access rules with policies and intercept request flow with middlewares.
- [Getters & usage](/cms/plugins-development/server-getters-usage): Access plugin controllers, services, content-types, and config through top-level and global getters.
- [Extending the MCP server](/cms/plugins-development/extend-mcp-server): Register custom MCP tools through the strapi.ai.mcp service so AI clients can trigger plugin-specific actions.

:::strapi Backend customization
Plugin routes, controllers, services, policies, and middlewares follow the same conventions as [backend customization](/cms/backend-customization) in a standard Strapi application. The Server API wraps these into the plugin namespace automatically (see [server content types](/cms/plugins-development/server-content-types#uids-and-naming-conventions) for details on UIDs and naming conventions).
:::