A key feature in Tyk is the ability to generate policies that give specific kinds of access rights, limits and quota’s to developers. This feature goes hand in hand with the API portal as it allows for a developer to sign up for API access and receive a key that has all the relevant access permissions and quotas set. It also means that it is easy to upgrade a user key to a higher tier of access by simply changing the policy that is assigned to their API Key
As described in the core PI documentation regarding policies, it is possible to set all the access rights and quotas just like you would when editing a standard developer key.
Policies can give access to multiple APIs if necessary, however this may not make much sense for API portal usage, as the portal will assign keys to API IDs that they are published with, however as this is a core feature of Policies it is also exposed in the portal.
Path based access
As well as the global access rules for ignored, white listed and black listed paths, you can set additional rules on a per-policy level to give users access to your API, for example, if you just wanted a user to have read-only access without having to create a new version of the API that describes the read-only endpoints.
Specifying these rules in this section will create a key-specific whitelist that is tested after the global rules have been passed.
Tags in a policy are a way to segment your API Analytics by groups of users. So for example if you wanted to know how many of your “Pro Tier” users are engaging with your services, then you can tag the policy, and all traffic generated by those policy holders (old and future) will immediately start being tracked in your analytics.
It is possible to create “Trial Keys” that expire after they have been created by the portal. These Keys, when created by being linked to a policy, will be created with an expiry date set in the future at the time period set out in this option.