Introduction

With Swashbuckle, you can keep an API action available in code while hiding it from generated Swagger or OpenAPI documentation. The normal approach is to exclude the action from API exploration or to remove it with a filter during document generation.

Hide a Method with ApiExplorerSettings

The simplest solution is to tell the API explorer to ignore the action:

1using System.Web.Http;
2using System.Web.Http.Description;
3
4public class AdminController : ApiController
5{
6    [ApiExplorerSettings(IgnoreApi = true)]
7    [HttpPost]
8    [Route("api/admin/reindex")]
9    public IHttpActionResult Reindex()
10    {
11        return Ok();
12    }
13
14    [HttpGet]
15    [Route("api/admin/status")]
16    public IHttpActionResult Status()
17    {
18        return Ok("ready");
19    }
20}

In that example, the route still exists, but Reindex is omitted from generated documentation because API discovery skips it.

Use This for Internal or Transitional Endpoints

This is a good fit when:

• an endpoint is internal
• an endpoint is temporary
• an endpoint should remain callable but should not be advertised publicly

It lets you keep the route while controlling what appears in the public API contract.

Filter Operations Centrally When Policy Is Broader

If the omission rule is broader than one or two actions, use a Swashbuckle filter. For example, you might hide all endpoints under an internal route prefix or remove every action marked with a custom attribute.

The important idea is that the filter edits the generated API description after discovery but before the final Swagger document is exposed. This is more flexible than decorating each action individually, but it is also less obvious to someone reading a single controller file.

Hidden Does Not Mean Disabled

Omitting an action from Swagger does not disable the endpoint. Clients can still call the route if it is reachable and authorized. That is why documentation visibility must never be treated as a security boundary.

If an endpoint is sensitive, combine documentation omission with proper authorization or routing restrictions. Swagger settings only affect what the generated document shows.

Use Attributes for Local Exceptions

If only one or two actions are internal, attribute-based hiding is usually easier to maintain than a centralized filter. A developer reading the controller can see immediately that the route is intentionally omitted from the API description, which reduces surprise during later maintenance.

Prefer the Smallest Mechanism That Fits

As a rule:

• use [ApiExplorerSettings(IgnoreApi = true)] when only a few actions need to disappear from docs
• use a filter when the hiding rule is cross-cutting

That keeps the documentation setup understandable instead of scattering hard-to-discover rules throughout the project. It also makes code review easier because the hiding decision stays close to the action being hidden.

Common Pitfalls

• Assuming a hidden Swagger method is no longer callable. The route still exists unless something else blocks it.
• Using documentation omission instead of authorization for internal endpoints.
• Adding broad filters without documenting the hiding policy for the team.
• Hiding endpoints that clients still depend on, causing confusion about the actual contract.
• Forgetting that API explorer visibility is often what drives Swashbuckle's generated output.

Summary

• The simplest way to omit a Web API action from Swashbuckle docs is [ApiExplorerSettings(IgnoreApi = true)].
• This hides the action from generated documentation without deleting the route.
• Use filters when the rule is broader than a few specific actions.
• Treat Swagger omission as visibility control, not security.
• Keep the hiding rule clear so future maintainers know why an endpoint is missing from the docs.