Skip to main content

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.

​
Introduction

While a Session dictates the overall limits and lifecycle for a client, the access_rights map is the engine that drives exactly what that client is allowed to do. The access_rights map links the Session to specific APIs and defines the boundaries of access within those APIs. This includes restricting access to specific endpoints (paths and HTTP methods), and even overriding the global session limits for a particular API.
While you can configure access_rights directly on a Session object, it is highly recommended to manage these settings via Policies for easier management at scale.

​
The Access Rights Map

Under the hood, access_rights is a map where the key is the API ID, and the value is an Access Definition object. If an API ID is not present in this map, the Session has absolutely no access to that API. If it is present, Tyk evaluates the rules defined in the Access Definition.

​
Basic API Access

At its simplest, an Access Definition grants access to an API identified by its unique ID:
  • api_id: The internal ID of the API.
  • api_name: A human-readable name for the API.

​
Granular Endpoint Access

By default, granting access to an API allows the client to access all paths and HTTP methods (endpoints) within that API. You can restrict this using the allowed_urls allow list.
  • allowed_urls: A list of objects that define specific endpoints the client can access. If this list is empty, all endpoints are allowed. If it contains even one entry, Tyk operates in a “default deny” mode, and the request must match an entry in this allow list to proceed.
Each entry in the allowed_urls allow list contains:
  • url: A regular expression pattern matching the allowed path (e.g., /users/.*).
  • methods: A list of allowed HTTP methods for that path (e.g., ["GET", "POST"]).
Example: Allowing read-only access to the /users endpoint: 
"allowed_urls": [
  {
    "url": "/users/.*",
    "methods": ["GET"]
  }
]

​
API-Level Limits and Quotas

Sometimes, you want a client to have different rate limits or quotas for different APIs. For example, a client might be allowed 100 requests per second globally, but only 10 requests per second to a computationally expensive “Reports” API. You can override the Session’s global limits (the rate limit and quota controls declared at the root of the session object) for a specific API using the limit object within the Access Definition.
  • limit: An object containing rate limit and quota settings that apply only to this API. If these fields are set, they take precedence over the global Session limits when the client accesses this specific API:
    • rate and per: The API-specific rate limit.
    • throttle_interval and throttle_retry_limit: The API-specific throttling configuration.
    • quota_max and quota_renewal_rate: The API-specific quota configuration.

​
Endpoint-Level Rate Limits

For even finer control, you can define rate limits for specific paths and methods within an API using the endpoints list.
  • endpoints: A list of objects that define rate limits for specific paths.
    • path: The exact path (e.g., /reports).
    • methods: A list of methods and their associated limits.
      • name: The HTTP method (e.g., GET).
      • limit: The rate limit configuration (rate and per) for this specific path and method.

​
Protocol-Specific Controls

The Access Definition also contains fields for securing specific types of APIs: GraphQL
  • restricted_types and allowed_types: Controls which GraphQL types the client can query.
  • field_access_rights: Granular control over specific fields within GraphQL types.
  • disable_introspection: Prevents the client from running introspection queries.
JSON-RPC and MCP
  • json_rpc_methods and json_rpc_methods_access_rights: Controls access to specific JSON-RPC methods.
  • mcp_primitives and mcp_access_rights: Controls access to specific Model Context Protocol (MCP) primitives.

​
Tyk Classic API Controls

If you are using Tyk Classic APIs, you can also restrict access to specific API versions:
  • versions: A list of strings representing the allowed versions (e.g., [“Default”, “v2”]). The client’s request must target one of these versions.
This field is ignored for Tyk OAS APIs, which are inherently unversioned from the Session’s perspective, as each has its own unique API ID.