Configuring No Auth for API Resources

The No Auth functionality allows you to bypass authentication for specific API endpoints. This is useful for public health-check endpoints, landing pages, or specific open data resources.

To configure No Auth, navigate through the following steps in the console:

Go to APIs > Your API.
Select API Configurations.
Select your Version and Deployment Region.
Scroll down to the No Auth Configuration section.

Path Matching Logic

When configuring paths, the system follows specific logic to determine if a request should be exempted from authentication:

Rule Type	Syntax Example	Behavior
Exact Match	`/product`	Impacts only the literal path.
Wildcard Match	`/product/*`	Impacts the path and all subsequent sub-paths.
Path Parameter	`/product/{id}`	Acts as a placeholder for specific resource IDs.
Root Exception	`/`	Opens the base URL only; does not propagate downward.

Validation Examples

Use the table below to understand how configured methods and resources interact with incoming requests.

Resource Methods	Configured Resource(s)	Target Request	Expected Result	Reason
GET	`GET /`	`GET v1/`	Success (200)	The base endpoint is configured for No Auth.
GET	`GET /`	`GET v3/orders`	Fail (401)	Sub-resources do not inherit root No-Auth.
GET	`GET /product`	`GET /product`	Success (200)	Exact match for No Auth.
GET	`GET /product/{name}`	`POST /product/apple`	Fail (401)	Method mismatch; POST requires Auth.
GET	`GET /product/*`	`GET /product/apple/detail`	Success (200)	Wildcard covers all deep sub-paths.
GET	`GET /product/*` + `GET /product/{id}`	`GET /product/apple`	Success (200)	Saved successfully; Wildcard covers the request.
GET	`GET /product/{id}` + `GET /product/*`	`GET /product/apple`	Success (200)	Saved successfully; Wildcard covers the request.
GET & POST	`POST /product`	`POST /product`	Success (2XX)	Exact match for No Auth.
GET / POST / PUT	`/prod/*`	`PUT /product/apple/ipad`	Success (2XX)	Wildcard covers all deep sub-paths.

Multi-Path Scenarios

Case A: Wildcard at Level 1

Config: GET /org/* (No Auth)
Request: GET /org/12/users/99
Result: Success (200)
Explanation: The level 1 wildcard opens every path segment following /org/.

Case B: Exact Match at Level 2

Config: GET /org/my-org/users (No Auth)
Request 1: GET /org/my-org/users → Success (200)
Request 2: GET /org/my-org → Fail (401)
Request 3: GET /org/my-org/users/admin → Fail (401)
Explanation: Because it is an exact match and not a wildcard, authentication is required as soon as you add a third path segment (/admin).

Case C: Path Parameter at Level 3

Config: GET /org/finance/users/{userId} (No Auth)
Request: GET /org/finance/users/bob123
Result: Success (200)
Explanation: Only the specific {userId} position is exempted. If the user tried GET /org/finance/settings, it would be Denied.

Case D: Root Resource is Exempted

Config: GET / (No Auth)
Request 1: GET / → Success (200)
Request 2: GET /org/my-org → Fail (401)
Request 3: GET /org/my-org/users/admin → Fail (401)
Explanation: Only the root resource is exempted. If the user tries any other path, it would be Denied.