How to create a API Key inherits all Access Rights from its Organisation?

My case is: All API KEY under an organization with same api access rights
Wanna create a new API KEY which inherit ALL access rights of its organization dynamically, so that no need to duplicate access_rights on every api key creation. Any hints ?


    "allowance": 1000,
    "rate": 1000,
    "per": 60,
    "expires": -1,
    "quota_max": -1,
    "quota_renews": 1406121006,
    "quota_remaining": 0,
    "quota_renewal_rate": 60,
    "access_rights": {
         // I don't want to put all API access rights of an Org on every key creation.
    "org_id": "53ac07777cbb8c2d53000002",
    "meta_data": {},
    "oauth_client_id": "",
    "oauth_keys": {},
    "basic_auth_data": {
        "password": "",
        "hash_type": ""
    "jwt_data": {
        "secret": ""
    "hmac_enabled": false,
    "hmac_string": "",
    "is_inactive": false,
    "apply_policy_id": "",
    "monitor": {
        "trigger_limits": []
    "tags": []

BTW, there are few typo on this Sample Request. e.g. oauth_keys oauth_client_id, apply_policy_id

You could do this:

If you only have one org.

If you have multiple Orgs, I’d say use a policy, and put a dummy / disabled API as the baseline into keys your are creating. Then you only need to manage the policy.

1 Like

Attached my preliminary design for sharing.

Objective: provide Public(Free) APIs and Paid Customer API
Tyk config design:

  • API Definitions on Files without org_id.
  • Define Policies on Files without org_id.
  • create API KEY via REST API /tyk/keys/create


  1. Any concern if I define API without org_id ? Doc said it is recommended
  2. Any concern if I define Policies without org_id ? Doc said it is recommended
  3. I tried GET but it always return empty keys. Why ? I am sure KEY with appropriate policy ( say client_policy_00001) can access client_00001
  4. Any API to list all Keys of an given Organisation
  5. Any API to list all Keys of using an given Policy

To answer your questions:

Yes, we strongly recommend that org_id’s are set on APIs, policies and keys, org ID’s basically group ownership of these obejcts, leaving them out could cause things to stop working (we’ve seen this with policies), not recommended

See above.

Tyk hashes keys, unless you have this switched off, listing keys will not work (by design). Also, the api_id param is not a filter, it is merely a specifier to identify the back-end to use (search the forum, this has been asked many times).

Yes, if you make the list keys GET request to the advanced API on an unhashed installation with a user that belongs to the org



Lastly, orgs are there to organise API / Resource ownership domains, not clients, so you can have one org, owning Evernote and LinkedIn APIs and supply keys for both. Then use policies to determine paid or free access to either.

You would only use multiple orgs if you actually want to segregate APIs, keys and ownership from one another, i.e. you have multiple tenants. And ultimately, this only matters in the dashboard, not in the gateway, as the dash/advanced API is the only thing that really cares and filters based on these criteria, and those filters only work if org_ids are used.