---
title: About API Enforcement
summary: null
url: >-
  https://www.fastly.com/documentation/guides/security/api-security/api-enforcement/about-api-enforcement
---

Fastly's [API Enforcement](https://docs.fastly.com/products/api-enforcement) product validates incoming API requests against schemas you define and logs or blocks requests that don't conform. It runs at Fastly's Edge on HTTP and HTTPS traffic proxied through your Fastly services.

## How it works

API Enforcement works by comparing incoming requests against a description of what your API is supposed to look like. You provide that description by uploading an [OpenAPI Specification (OAS)](https://spec.openapis.org/oas/) file, which is the same kind of file many teams already use to document their APIs. API Enforcement reads the OAS file to learn which endpoints exist and what valid requests to those endpoints look like, and then uses that knowledge to evaluate live traffic. Requests that match your specification pass through normally. Requests that don't match are either logged for review or mitigated outright, depending on your configured settings.

To get started, you enable API Enforcement on a Fastly service, upload one or more OAS files, and select a protection mode for your uploaded operations. We recommend starting in logging mode so you can review how API Enforcement classifies your traffic before switching to blocking. You can define validation rules for individual operations in your API. Each operation is identified by its domain, URL path, and HTTP method.

### API request handling

When Fastly receives a request to your API, API Enforcement matches it against the corresponding operation in your schema and validates the HTTP method, domain, URL path, and query parameters. Conforming requests pass through to your origin. Nonconforming requests are logged or blocked depending on your protection mode.

The following examples illustrate how API Enforcement classifies requests:

| Request                                                               | Schema definition                                                                                                            | Result                                                                                           |
| --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| `GET api.example.com/v1/anna`                                         | None                                                                                                                         | **No match** — the endpoint is not defined in any uploaded schema                                |
| `GET api.example.com/v1/users/abc`                                    | `/users/{userId}`: `userId` in path, `type: integer`                                                                         | **No match** — `abc` is not an integer                                                           |
| `POST api.example.com/v1/users/123456/actions/purge/a2984hskdj384klj` | `/users/{userId}/actions/purge/{itemId}`: `userId` in path `type: integer`; `itemId` in path `type: string`, `maxLength: 10` | **No match** — the `itemId` value `a2984hskdj384klj` exceeds the maximum length of 10 characters |

### Protection modes

API Enforcement has three protection modes that are configured at the operation level:

- **Logging mode** (default) monitors traffic and logs nonconforming requests without blocking them. Use this mode to observe how API Enforcement detects invalid requests before enabling stricter controls.
- **Blocking mode** blocks nonconforming requests at the edge before they reach your origin. Blocking mode also logs the same details as logging mode.
- **Off mode** pauses all validation, logging, and blocking without removing your uploaded schemas or inventory operations. No usage metrics are emitted while in off mode.

## Schema uploads and API Inventory

API Enforcement uses [API Inventory](https://www.fastly.com/documentation/guides/security/api-security/api-inventory/) as its source of truth for validation. When you upload an OAS file, API Enforcement parses it for API operations (defined as a combination of domain, URL path, and HTTP method) and saves them to your API Inventory. API Enforcement then validates against those saved operations.

### What happens when you upload a schema

After you select a file to upload, API Enforcement parses it and shows you a preview of the operations it found before anything is saved. Each operation is classified as one of the following:

- **New:** The operation does not currently exist in your inventory. This includes operations that have been seen by API Discovery, operations that were previously ignored, and operations that have never been seen by Fastly at all. All are added to inventory and linked to the uploaded schema file.
- **Update:** The operation already exists in your inventory. Its existing description and tags are appended with whatever is most recently provided, and its schema association is updated to point to the newly uploaded file.

The preview shows how many operations were found in total. You review the findings before any changes are saved to API Inventory.

Uploads are all-or-nothing. You can't selectively choose which operations from a file to save. All operations in the file are saved to inventory when you confirm the upload. Any tags defined in your OAS file are also ingested and saved to inventory alongside the operations they apply to.

If the same operation appears in multiple uploaded schema files, it is linked to the most recently uploaded file containing its definition. If you later delete that newer file, the operation's link is not automatically reassigned to an older file.

> **HINT:** A link to a schema file can be reestablished by uploading it again.

### Schema file management

After uploading, you can view all of your schema files in **Security** > **API Security** > **Schemas**. For each file, you can see its name, size, upload date, and how many inventory operations are currently associated with it. You can download or delete any file at any time.

Deleting a schema file removes the association between that file and its operations, but does not remove the operations themselves from inventory. Deleting an operation from inventory removes the operation and its schema link, but does not affect other operations associated with the same file.

### Using with API Discovery

API Enforcement can be used with or without [API Discovery](https://www.fastly.com/documentation/guides/security/api-security/api-discovery/about-api-discovery). API Inventory remains active as long as either product is enabled on your service. If you later enable API Discovery on a service that already has schema-defined operations in API Inventory, those operations will not be duplicated.

> **HINT:** Some features in API Inventory will not available unless you have both API Enforcement and API Discovery enabled.

## Security products note

No security product, such as a WAF or DDoS mitigation product, including those security services offered by Fastly, will detect or prevent all possible attacks or threats. As a subscriber, you should maintain appropriate security controls on all web applications and origins. The use of Fastly's security products does not relieve you of this obligation. As a subscriber, you should test and validate the effectiveness of Fastly's security services to the extent possible prior to deploying these services in production, continuously monitor their performance, and adjust these services as appropriate to address changes in your web applications, origin services, and configurations of the other aspects of your Fastly services.
