Create Organisations, Users, Api Definitions, Key

I would like to know when using your api for creating the following objects:

  • Organisations
  • Api definitions
  • Keys
  • Users

If we can pass some kind of validation on request for preventing duplicates? Instead of going first to the server validating if some object already exists and reporting back. I would like to prevent the double roundtrip.


Hi Carlos,

I’m afraid not, you’ll need to manage that yourself. There is some limited validation in place for users, and API definitions have programatically generated API IDs (unless you are fixing them). Keys, unless being added are generated as well so they should always be unique.

If you are using the gateway API and are adding a key, then adding a duplicate will just overwrite the existing one.

Ah ok ,

Another question about creation API definitions, keys, and users.

For forming the http request to the rest api for this objects I need an Authorization header.

Can you please tell me where can i get this id? I see in google chrome that you are passing a guid for this but i can’t understand where does it come from.


For the advanced API you’ll find that with your username in the dashboard, just visit your user (or create a new one for the client) and there will be an API key area under the user details.

For th admin API (org creation) you will need to use the secret that is stored in your Tyk analytics conf file.

Hope that helps!


I’m sorry but i don’t understand.

My workflow is as follows:
Create organization (use admin-auth header)
Create API Definition(using authorization header and having error because don’t know where can i read it from because i don’t have yet a user)
Create Key(using authorization header and having error because don’t know where can i read it from because i don’t have yet a user)
Create User(using authorization header and having error because don’t know where can i read it from because i don’t have yet a user)

Hi Carlos,

You should:

  • Create organisation (admin auth)
  • Store org id
  • Create dashboard user (with admin auth) that is bound to org id, this returns your API key
  • Compete rest of flow

A “User” here is a dashboard user - in this case think of it like a slack bot.

If you mean you want to create a portal developer that’s different. You’ll still need a dashboard user to perform actions as.

Take a look at the setup script we use to bootstrap the docker QuickStart - it does it all with the API, the only things missing are key and API creation :slight_smile:

Hope that’s clearer.


Hello Martin,

I still having issues with my workflow. I can successfully create Organisations and User using Admin API but then when triyng to create API Definition it says to me that authorization is missing. I’m passing , like you said, the API Dashboard Access Key calculate from response.acess_key. What I’m doing wrong? By the way it will be the same problem for Key Creation. Can you please send a successful requests that so i can proceed?


For API creation what header name are you using for auth? They are different for admin and advanced API

I’m using like so:

var headers = options.token ?
{‘admin-auth’: options.token} :
{‘authorization’: options.authorization};

Admin API;

Advanced API:

Here’s an API creation request (lifted from docs) - just ran this with Postman against my local box:

Request URL:
Request Method:POST

Accept-Encoding:gzip, deflate

    "api_definition": {
        "name": "Test API 2",
        "auth": {
            "auth_header_name": "authorization"
        "definition": {
            "location": "header",
            "key": ""
        "proxy": {
            "target_url": ""
        "version_data": {
            "use_extended_paths": true,
            "not_versioned": true,
            "versions": {
                "Default": {
                    "expires": "",
                    "name": "Default",
                    "paths": {
                        "ignored": [],
                        "white_list": [],
                        "black_list": []
                    "extended_paths": {
                        "ignored": [
                                "path": "/test-path/",
                                "method_actions": {
                                    "GET": {
                                        "action": "no_action",
                                        "code": 200,
                                        "data": "",
                                        "headers": {}
                                "path": "/test-path/reply",
                                "method_actions": {
                                    "GET": {
                                        "action": "reply",
                                        "code": 200,
                                        "data": "{\"foo\": \"bar\"}",
                                        "headers": {
                                            "x-test": "test"
                        "white_list": [],
                        "black_list": []
                    "use_extended_paths": true
        "use_oauth2": false,
        "oauth_meta": {
            "auth_login_redirect": "",
            "allowed_access_types": [],
            "allowed_authorize_types": [
        "notifications": {
            "shared_secret": "",
            "oauth_on_keychange_url": ""
        "enable_ip_whitelisting": true,
        "allowed_ips": [
        "use_keyless": false,
        "enable_signature_checking": false,
        "use_basic_auth": false,
        "active": true,
        "enable_batch_request_support": true
    "hook_references": [
            "event_name": "QuotaExceeded",
            "hook": {
                "api_model": {},
                "id": "54be6c0beba6db07a6000002",
                "org_id": "54b53d3aeba6db5c35000002",
                "name": "Test Post",
                "method": "POST",
                "target_path": "",
                "template_path": "",
                "header_map": {
                    "x-tyk-test": "123456"
                "event_timeout": 0
            "event_timeout": 60

Response was:

    "Status": "OK",
    "Message": "API created",
    "Meta": "56a1076130c55e6c66000006"

It’s working :slightly_smiling:

But for the creating an API Key it gives a different error…

User does not have permission to add API to key Access Rights …

Does the user belong to the same org as the API?

Hello Martin,

Yes I have the correspondent org and user and api on the same group. So to that I log in to dashboard and I see the correspondent objects. What it strange is that if analyse your request and responses on google chrome all works but when I simulate the same behavior on my code it doesn’t work. At the moment is giving me Failed to save new session object to Tyk: Could not create key for this API ID, API doesn’t exist. Another error happened to me already when i use a test script on packgage.json when starting my docker container complaining that the tyk object is not defined. And to resolve this issue i have to update the API and try to generate the new key. Furthermore I have also developed the same update to the api definition but with no success.

What can I be missing?

Ah! Ok, so when you create a key with the Advanced API, what happens is:

CREATE key request -> [Advanced API] Gateway Wrapper -> [Tyk Gateway API] CREATE Key

Basically the dashboard validates the request and then instructs the gateway to generate the token, the dashboard (advanced API) doesn’t generate the token directly.

So, if you create an API in the dashboard, it will save it, and signal to Tyk Gateway to load the API (hot reload).

Tyk gateway has a timed load for these signals so they batch if lots of updates happen at the same time (to prevent constant, or back-to-back reloads). If your CREATE command is happening too quickly, the API will not exist on the gateway yet, and therefore the key cannot be created since it is attached to an API that the gateway won’t recognise, and so the request fails up the chain.

The trick is to wait for the API to be loaded in Tyk (say 5 secs or so) before creating keys. You can see the reload live if you tail the logs on save an API definition to get the timing.

Hello Martin,

I tried to await before calling the api (/api/keys) creating method. I tried with a 50 seconds timeout and I could not make it work. It gives the sames error. :frowning:

Ok, we’ll need to debug your setup then:

  1. Is your API Gateway hot reloading when you create an API (there will be a status message, a pause, then the reload output with all the APIs that are loading)
  • Can you create a key manually in the dashboard? Or do you get the same error message?


Yes it’s reloading.
And yes i can on dashboard create keys successfully. In the browser manually creating the time i have between api creation and dashboard is significant that the tyk reloads the api. The problem is when i use my api. Currently i can make a first request and create api but next ones are failing. :frowning:

We need to go deeper, can you share your request bodies?

Hello Martin,

Sorry the late response, :frowning:

My requests I can only share small details . Concretely what you need to know?

To debug this we can’t help if its blind, and I don’t know what I’m looking for, but your client is doing something fundamentally wrong:

  • The API that you are using is the same API that is used by the dashboard (literally, the GUI is an Advanced API web client, it does nothing special or privileged)
  • If the command is possible with the dashboard then the problem isn’t your configuration, isn’t your architecture and isn’t not something wrong with your API configuration.

Can you at least share your log output when the requests run (with error) for the dashboard and for the gateway?

Beyond that, I can’t help debug if I don’t know what is being sent.

Also, I have no idea what this is:

We don’t use a package.json, so I’m not sure how your docker container is set up, are you using our containers or something proprietary (are you talking about