forked from TykTechnologies/tyk
-
Notifications
You must be signed in to change notification settings - Fork 0
/
swagger.yml
2743 lines (2689 loc) · 87.8 KB
/
swagger.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
openapi: 3.0.0
info:
title: Tyk Gateway API
version: 3.2.0
description: |-
The Tyk Gateway API is the primary means for integrating your application with the Tyk API Gateway system. This API is very small, and has no granular permissions system. It is intended to be used purely for internal automation and integration.
**Warning: Under no circumstances should outside parties be granted access to this API.**
The Tyk Gateway API is capable of:
* Managing session objects (key generation)
* Managing and listing policies
* Managing and listing API Definitions (only when not using the Dashboard)
* Hot reloads / reloading a cluster configuration
* OAuth client creation (only when not using the Dashboard)
In order to use the Gateway API, you'll need to set the `secret` parameter in your tyk.conf file.
The shared secret you set should then be sent along as a header with each Gateway API Request in order for it to be successful:
```
x-tyk-authorization: <your-secret>
```
<br/>
<b>The Tyk Gateway API is subsumed by the Tyk Dashboard API in Pro installations.</b>
servers:
- url: 'http://localhost/'
- url: 'https://localhost/'
tags:
- name: Keys
description: |-
All keys that are used to access services via Tyk correspond to a session object that informs Tyk about the context of this particular token, like access rules and rate/quota allowance.
- name: OAuth
description: |-
Manage OAuth clients, and manage their tokens
- name: Cache Invalidation
description: |-
Sometimes a cache might contain stale data, or it may just need to be cleared because of an invalid configuration. This call will purge all keys associated with a cache on an API-by-API basis.
- name: Hot Reload
description:
Force restart of the Gateway or whole cluster
- name: Health Checking
description: Check health check of the Gateway and loaded APIs
- name: Organisation Quotas
description: |-
It is possible to force API quota and rate limit across all keys that belong to a specific organisation ID. Rate limiting at an organisation level is useful for creating tiered access levels and trial accounts.
The Organisation rate limiting middleware works with both Quotas and Rate Limiters. In order to manage this functionality, a simple API has been put in place to manage these sessions.
Although the Organisation session-limiter uses the same session object, all other security keys are optional as they are not used.
<h3>Managing active status</h3>
To disallow access to an entire group of keys without rate limiting the organisation, create a session object with the "is_inactive" key set to true. This will block access before any other middleware is executed. It is useful when managing subscriptions for an organisation group and access needs to be blocked because of non-payment.
- name: Batch requests
description: |-
Tyk supports batch requests, so a client makes a single request to the API but gets a compound response object back.
This is especially handy if clients have complex requests that have multiple synchronous dependencies and do not wish to have the entire request / response cycle running for each event.
To enable batch request support, set the `enable_batch_request_support` value to `true`
This is especially handy if clients have complex requests that have multiple synchronous dependencies and do not wish to have the entire request / response cycle running for each event.
Batch requests that come into Tyk are *run through the whole Tyk machinery* and *use a relative path to prevent spamming*. This means that a batch request to Tyk for three resources with the same API key will have three requests applied to their session quota and request limiting could become active if they are being throttled.
Tyk reconstructs the API request based on the data in the batch request. This is to ensure that Tyk is not being used to proxy requests to other hosts outside of the upstream API being accessed.
Batch requests are created by POSTing to the `/{listen_path}/tyk/batch/` endpoint. These requests **do not require a valid key**, but their request list does.
<h3>Sample Request</h3>
```{json}
{
"requests": [
{
"method": "GET",
"headers": {
"x-tyk-test": "1",
"x-tyk-version": "1.2",
"authorization": "1dbc83b9c431649d7698faa9797e2900f"
},
"body": "",
"relative_url": "get"
},
{
"method": "GET",
"headers": {
"x-tyk-test": "2",
"x-tyk-version": "1.2",
"authorization": "1dbc83b9c431649d7698faa9797e2900f"
},
"body": "",
"relative_url": "get"
}
],
"suppress_parallel_execution": false
}
```
The response will will be a structured reply that encapsulates the responses for each of the outbound requests. If `suppress_parallel_execution` is set to `true`, requests will be made synchronously. If set to `false` then they will run in parallel and the response order is not guaranteed.
<h3>Sample Response</h3>
```
[
{
"relative_url": "get",
"code": 200,
"headers": {
"Access-Control-Allow-Credentials": [
"true"
],
"Access-Control-Allow-Origin": [
"*"
],
"Content-Length": [
"497"
],
"Content-Type": [
"application/json"
],
"Date": [
"Wed, 12 Nov 2014 15:32:43 GMT"
],
"Server": [
"gunicorn/18.0"
],
"Via": [
"1.1 vegur"
]
},
"body": "{
"args": {},
"headers": {
"Accept-Encoding": "gzip",
"Authorization": "1dbc83b9c431649d7698faa9797e2900f",
"Connect-Time": "2",
"Connection": "close",
"Host": "httpbin.org",
"Total-Route-Time": "0",
"User-Agent": "Go 1.1 package http",
"Via": "1.1 vegur",
"X-Request-Id": "6a22499a-2776-4aa1-80c0-686581a8be4d",
"X-Tyk-Test": "2",
"X-Tyk-Version": "1.2"
},
"origin": "127.0.0.1, 62.232.114.250",
"url": "http://httpbin.org/get"
}"
},
{
"relative_url": "get",
"code": 200,
"headers": {
"Access-Control-Allow-Credentials": [
"true"
],
"Access-Control-Allow-Origin": [
"*"
],
"Content-Length": [
"497"
],
"Content-Type": [
"application/json"
],
"Date": [
"Wed, 12 Nov 2014 15:32:43 GMT"
],
"Server": [
"gunicorn/18.0"
],
"Via": [
"1.1 vegur"
]
},
"body": "{
"args": {},
"headers": {
"Accept-Encoding": "gzip",
"Authorization": "1dbc83b9c431649d7698faa9797e2900f",
"Connect-Time": "7",
"Connection": "close",
"Host": "httpbin.org",
"Total-Route-Time": "0",
"User-Agent": "Go 1.1 package http",
"Via": "1.1 vegur",
"X-Request-Id": "1ab61f50-51ff-4828-a7e2-17240385a6d2",
"X-Tyk-Test": "1",
"X-Tyk-Version": "1.2"
},
"origin": "127.0.0.1, 62.232.114.250",
"url": "http://httpbin.org/get"
}"
}
]
```
With the body for each request string encoded in the `body` field.
* `expire_analytics_after`: If you are running a busy API, you may want to ensure that your MongoDB database does not overflow with old data. Set the `expire_analytics_after` value to the number of seconds you would like the data to last for. Setting this flag to anything above `0` will set an `expireAt` field for each record that is written to the database.
**Important:** Tyk will not create the expiry index for you. In order to implement data expiry for your analytics data, ensure that the index is created This is easily achieved using the [MongoDB command line interface](https://docs.mongodb.com/getting-started/shell/client/).
* `dont_set_quota_on_create`: This setting defaults to `false`, but if set to `true`, when the API is used to edit, create or add keys, the quota cache in Redis will not be re-set. By default, all updates or creates to Keys that have Quotas set will re-set the quota (This has been the default behaviour since 1.0).
This behaviour can be bypassed on a case-by-case basis by using the `suppress_reset` parameter when making a REST API request. This is the advised mode of operation as it allows for manual, granular control over key quotas and reset timings.
* `cache_options`: This section enables you to configure the caching behaviour of Tyk and to enable or disable the caching middleware for your API.
* `cache_options.enable_cache`: Set this value to `true` if the cache should be enabled for this endpoint, setting it to false will stop all caching behaviour.
* `cache_options.cache_timeout`: The amount of time, in seconds, to keep cached objects, defaults to `60` seconds.
* `cache_options.cache_all_safe_requests`: Set this to `true` if you want all *safe* requests (GET, HEAD, OPTIONS) to be cached. This is a blanket setting for APIs where caching is required but you don't want to set individual paths up in the definition.
* `cache_options.enable_upstream_cache_control`: Set this to `true` if you want your application to control the cache options for Tyk (TTL and whether to cache or not). See [Caching](/docs/basic-config-and-security/reduce-latency/caching/) for more details.
* `response_processors`: Response processors need to be specifically defined so they are loaded on API creation, otherwise the middleware will not fire. In order to have the two main response middleware components fire, the following configuration object should be supplied.
```{json}
"response_processors": [
{
"name": "header_injector",
"options": {
"add_headers": {"name": "value"},
"remove_headers": ["name"]
}
},
{
"name": "response_body_transform",
"options": {}
}
]
```
The options for the `header_injector` are global, and will apply to all outbound requests.
- name: APIs
description: |-
**Note: Applies only to Tyk Gateway Community Edition**
API Management is very simple using the Tyk REST API: each update only affects the underlying file, and this endpoint will only work with disk based installations, not Database-backed ones.
APIs that are added this way are flushed to to disk into the app_path folder using the format: `{api-id}.json`. Updating existing APIs that use a different naming convention will cause those APIs to be added, which could subsequently lead to a loading error and crash if they use the same listen_path.
These methods only work on a single API node. If updating a cluster, it is important to ensure that all nodes are updated before initiating a reload.
paths:
'/tyk/apis':
get:
description: |-
List APIs
Only if used without the Tyk Dashboard
tags:
- APIs
operationId: listApis
responses:
'200':
description: List of API definitions
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/APIDefinition'
example:
- name: "TestAPI"
use_keyless: true
active: true
proxy:
listen_path: "/test"
post:
description: |-
Create API
A single Tyk node can have its API Definitions queried, deleted and updated remotely. This functionality enables you to remotely update your Tyk definitions without having to manage the files manually.
tags:
- APIs
operationId: createApi
requestBody:
content:
application/json:
schema:
$ref: "#/components/schemas/APIDefinition"
example:
name: "TestAPI"
use_keyless: true
active: true
proxy:
listen_path: "/test"
responses:
'200':
description: API created
content:
application/json:
schema:
$ref: "#/components/schemas/apiModifyKeySuccess"
example:
status: "ok"
action: "created"
key: "{...API JSON definition...}"
'400':
description: Malformed data
content:
application/json:
schema:
$ref: "#/components/schemas/apiStatusMessage"
example:
status: "error"
message: "Malformed API data"
'/tyk/apis/{apiID}':
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
get:
description: |-
Get API definition
Only if used without the Tyk Dashboard
tags:
- APIs
operationId: getApi
responses:
'200':
description: API definition
content:
application/json:
schema:
$ref: "#/components/schemas/APIDefinition"
example:
name: "TestAPI"
use_keyless: true
active: true
proxy:
listen_path: "/test"
put:
description: |
Updating an API definition uses the same signature an object as a `POST`, however it will first ensure that the API ID that is being updated is the same as the one in the object being `PUT`.
Updating will completely replace the file descriptor and will not change an API Definition that has already been loaded, the hot-reload endpoint will need to be called to push the new definition to live.
tags:
- APIs
operationId: updateApi
requestBody:
content:
application/json:
schema:
$ref: "#/components/schemas/APIDefinition"
example:
name: "TestAPI"
use_keyless: true
active: true
proxy:
listen_path: "/test"
responses:
'200':
description: API updated
content:
application/json:
schema:
$ref: "#/components/schemas/apiModifyKeySuccess"
example:
status: "ok"
action: "updated"
key: "{...API JSON definition...}"
'400':
description: Malformed data
content:
application/json:
schema:
$ref: "#/components/schemas/apiStatusMessage"
example:
status: "error"
message: "Malformed API data"
delete:
description: |-
Deleting an API definition will remove the file from the file store, the API definition will NOT be unloaded, a separate reload request will need to be made to disable the API endpoint.
tags:
- APIs
operationId: deleteApi
responses:
'200':
description: API deleted
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
message: API deleted
status: ok
'400':
description: No API ID specified
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
message: API ID not specified
status: error
'/tyk/cache/{apiID}':
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
delete:
summary: Invalidate cache
description: Invalidate cache for given API
tags:
- Cache Invalidation
operationId: invalidateCache
responses:
'200':
description: Invalidate cache
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
message: cache invalidated
status: ok
'/tyk/reload/':
get:
summary: Hot-reload a single node
description: Tyk is capable of reloading configurations without having to stop serving requests, this means that API configurations can be added at runtime, or even modified at runtime and those rules applied immediately without any downtime.
parameters:
- description: Block a response, until the reload is performed. This can be useful in scripting environments like CI/CD workflows.
name: block
in: query
required: false
schema:
type: boolean
enum: [true]
tags:
- Hot Reload
operationId: hotReload
responses:
'200':
description: Reload gateway
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
status: ok
'/tyk/reload/group':
get:
summary: Hot-reload a Tyk group
description: To reload a whole group of Tyk nodes (without using the Dashboard or host manager), you can send an API request to a single node, this node will then send a notification through the pub/sub infrastructure to all other listening nodes (including the host manager if it is being used to manage NginX) which will then trigger a global reload.
tags:
- Hot Reload
operationId: hotReloadGroup
responses:
'200':
description: Reload gateway
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
status: ok
'/tyk/hello':
get:
summary: Check the Health of the Gateway
description: |
From v2.7.5 you can now rename the `/hello` endpoint by using the `health_check_endpoint_name` option
Returns 200 response in case of success
tags:
- Health Checking
operationId: hello
responses:
'200':
description: Success
content:
text/html:
schema:
type: string
example: "Hello Tiki"
'/tyk/{listenPath}/hello':
parameters:
- in: path
name: listenPath
required: true
description: "Listen path of loaded API"
schema:
type: string
get:
summary: Check the Health of the API
description: Should point to API domain if it has own
tags:
- Health Checking
operationId: helloAPI
responses:
'200':
description: Success
content:
text/html:
schema:
type: string
example: "Hello Tiki"
'/tyk/keys':
get:
summary: List Keys
description: You can retrieve all the keys in your Tyk instance. Returns an array of Key IDs.
tags:
- Keys
operationId: listKeys
responses:
'200':
description: List of all API keys
content:
application/json:
schema:
$ref: "#/components/schemas/apiAllKeys"
post:
summary: Create a key
description: |-
Tyk will generate the access token based on the OrgID specified in the API Definition and a random UUID. This ensures that keys can be "owned" by different API Owners should segmentation be needed at an organisational level.
<br/><br/>
API keys without access_rights data will be written to all APIs on the system (this also means that they will be created across all SessionHandlers and StorageHandlers, it is recommended to always embed access_rights data in a key to ensure that only targeted APIs and their back-ends are written to.
tags:
- Keys
operationId: addKey
requestBody:
content:
application/json:
schema:
$ref: "#/components/schemas/SessionState"
example:
quota_max: 60
quota_renews: 1406121006
quota_renewal_rate: 60
allowance: 100
rate: 100
per: 5
org_id: 53ac07777cbb8c2d53000002
responses:
'200':
description: New Key added
content:
application/json:
schema:
$ref: '#/components/schemas/apiModifyKeySuccess'
example:
action: created
key: '{...KEY JSON definition...}'
status: ok
'400':
description: Malformed data
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
message: Malformed Key data
status: error
'/tyk/keys/{keyID}':
parameters:
- description: The Key ID
name: keyID
in: path
required: true
schema:
type: string
get:
summary: Get a Key
description: Get session info about the specified key. Should return up to date rate limit and quota usage numbers.
tags:
- Keys
operationId: getKey
responses:
'200':
description: Key object
content:
application/json:
schema:
$ref: '#/components/schemas/SessionState'
example:
quota_max: 60
quota_renews: 1406121006
quota_renewal_rate: 60
allowance: 100
rate: 100
per: 5
org_id: 53ac07777cbb8c2d53000002
put:
summary: Update Key
description: |-
You can also manually add keys to Tyk using your own key-generation algorithm. It is recommended if using this approach to ensure that the OrgID being used in the API Definition and the key data is blank so that Tyk does not try to prepend or manage the key in any way.
tags:
- Keys
operationId: updateKey
requestBody:
content:
application/json:
schema:
$ref: "#/components/schemas/SessionState"
example:
quota_max: 60
quota_renews: 1406121006
quota_renewal_rate: 60
allowance: 100
rate: 100
per: 5
org_id: 53ac07777cbb8c2d53000002
parameters:
- description: |-
Adding the suppress_reset parameter and setting it to 1, will cause Tyk not to reset the quota limit that is in the current live quota manager. By default Tyk will reset the quota in the live quota manager (initialising it) when adding a key. Adding the `suppress_reset` flag to the URL parameters will avoid this behaviour.
name: suppress_reset
in: query
required: false
schema:
type: string
enum: ["1"]
responses:
'200':
description: Key updated
content:
application/json:
schema:
$ref: '#/components/schemas/apiModifyKeySuccess'
example:
action: updated
status: ok
'400':
description: No or incorrect Key ID specified
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
message: Key ID not specified
status: error
post:
summary: Create Custom Key / Import Key
description: |-
You can use the `POST /tyk/keys/{KEY_ID}` endpoint as defined below to import existing keys into Tyk.
This example uses standard `authorization` header authentication, and assumes that the Gateway is located at `127.0.0.1:8080` and the Tyk secret is `352d20ee67be67f6340b4c0605b044b7` - update these as necessary to match your environment.
To import a key called `mycustomkey`, save the JSON contents as `token.json` (see example below), then run the following Curl command.
```
curl http://127.0.0.1:8080/tyk/keys/mycustomkey -H 'x-tyk-authorization: 352d20ee67be67f6340b4c0605b044b7' -H 'Content-Type: application/json' -d @token.json
```
The following request will fail as the key doesn't exist.
```
curl http://127.0.0.1:8080/quickstart/headers -H 'Authorization. invalid123'
```
But this request will now work, using the imported key.
```
curl http://127.0.0.1:8080/quickstart/headers -H 'Authorization: mycustomkey'
```
<h4>Example token.json file<h4>
```
{
"allowance": 1000,
"rate": 1000,
"per": 60,
"expires": -1,
"quota_max": -1,
"quota_renews": 1406121006,
"quota_remaining": 0,
"quota_renewal_rate": 60,
"access_rights": {
"3": {
"api_name": "Tyk Test API",
"api_id": "3"
}
},
"org_id": "53ac07777cbb8c2d53000002",
"basic_auth_data": {
"password": "",
"hash_type": ""
},
"hmac_enabled": false,
"hmac_string": "",
"is_inactive": false,
"apply_policy_id": "",
"apply_policies": [
"59672779fa4387000129507d",
"53222349fa4387004324324e",
"543534s9fa4387004324324d"
],
"monitor": {
"trigger_limits": []
}
}
```
tags:
- Keys
operationId: createCustomKey
requestBody:
content:
application/json:
schema:
$ref: "#/components/schemas/SessionState"
example:
quota_max: 60
quota_renews: 1406121006
quota_renewal_rate: 60
allowance: 100
rate: 100
per: 5
org_id: 53ac07777cbb8c2d53000002
parameters:
- description: |-
Adding the suppress_reset parameter and setting it to 1, will cause Tyk not to reset the quota limit that is in the current live quota manager. By default Tyk will reset the quota in the live quota manager (initialising it) when adding a key. Adding the `suppress_reset` flag to the URL parameters will avoid this behaviour.
name: suppress_reset
in: query
required: false
schema:
type: string
enum: ["1"]
responses:
'200':
description: Key updated
content:
application/json:
schema:
$ref: '#/components/schemas/apiModifyKeySuccess'
example:
action: updated
status: ok
'400':
description: No or incorrect Key ID specified
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
message: Key ID not specified
status: error
delete:
summary: Delete Key
description: Deleting a key will remove it permanently from the system, however analytics relating to that key will still be available.
tags:
- Keys
operationId: deleteKey
responses:
'200':
description: Key deleted
content:
application/json:
schema:
$ref: '#/components/schemas/apiStatusMessage'
example:
action: Key deleted
status: ok
'/tyk/oauth/clients/create':
post:
summary: Create new OAuth client
description: Any OAuth keys must be generated with the help of a client ID. These need to be pre-registered with Tyk before they can be used (in a similar vein to how you would register your app with Twitter before attempting to ask user permissions using their API).
<br/><br/>
<h3>Creating OAuth clients with Access to Multiple APIs</h3>
New from Tyk Gateway 2.6.0 is the ability to create OAuth clients with access to more than one API. If you provide the api_id it works the same as in previous releases. If you don't provide the api_id the request uses policy access rights and enumerates APIs from their setting in the newly created OAuth-client.
tags:
- OAuth
operationId: createOAuthClient
requestBody:
content:
application/json:
schema:
$ref: "#/components/schemas/NewClientRequest"
example:
client_id: test
api_id: id
policy_id: policy
responses:
'200':
description: Client created
content:
application/json:
schema:
$ref: '#/components/schemas/NewClientRequest'
example:
client_id: test
api_id: id
policy_id: policy
'/tyk/oauth/clients/{apiID}':
put:
summary: Update OAuth metadata and Policy ID
description: Allows you to update the metadata and Policy ID for an OAuth client.
tags:
- OAuth
operationId: updateoAuthClient
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
responses:
'200':
description: OAuth client metadata updated
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/NewClientRequest'
get:
summary: List oAuth clients
description: OAuth Clients are organised by API ID, and therefore are queried as such.
tags:
- OAuth
operationId: listOAuthClients
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
responses:
'200':
description: Get OAuth client details or a list of OAuth clients
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/NewClientRequest'
'/tyk/oauth/clients/{apiID}/{keyName}':
get:
summary: Get OAuth client
tags:
- OAuth
operationId: getOAuthClient
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
minimum: 1
- description: The Client ID
name: keyName
in: path
required: true
schema:
type: string
responses:
'200':
description: Get OAuth client details or a list of OAuth clients
content:
application/json:
schema:
$ref: '#/components/schemas/NewClientRequest'
example:
client_id: test
api_id: id
policy_id: policy
delete:
summary: Delete OAuth client
description: Please note that tokens issued with the client ID will still be valid until they expire.
tags:
- OAuth
operationId: deleteOAuthClient
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
minimum: 1
- description: The Client ID
name: keyName
in: path
required: true
schema:
type: string
responses:
'200':
description: OAuth client deleted
content:
application/json:
schema:
$ref: '#/components/schemas/apiModifyKeySuccess'
example:
action: deleted
status: ok
'/tyk/oauth/clients/{apiID}/{keyName}/tokens':
get:
summary: List tokens
description: This endpoint allows you to retrieve a list of all current tokens and their expiry date for a provided API ID and OAuth-client ID in the following format. This endpoint will work only for newly created tokens.
<br/>
<br/>
You can control how long you want to store expired tokens in this list using `oauth_token_expired_retain_period` gateway option, which specifies retain period for expired tokens stored in Redis. By default expired token not get removed. See <a href="https://tyk.io/docs/configure/tyk-gateway-configuration-options/#a-name-oauth-token-expired-retain-period-a-oauth-token-expired-retain-period" target="_blank">here</a> for more details.
tags:
- OAuth
operationId: getOAuthClientTokens
parameters:
- description: The API ID
name: apiID
in: path
required: true
schema:
type: string
minimum: 1
- description: The Client ID
name: keyName
in: path
required: true
schema:
type: string
responses:
'200':
description: Get a list of tokens
content:
application/json:
schema:
type: array
items:
type: string
example:
- "tok1"
- "tok2"
'/tyk/oauth/revoke':
post:
description: revoke a single token
summary: revoke token
requestBody:
required: true
content:
application/x-www-form-urlencoded:
schema:
type: object
properties:
token:
description: token to be revoked
type: string
client_id:
description: id of oauth client
type: string
token_type_hint:
description: type of token to be revoked, if sent then the accepted values are access_token and refresh_token. String value and optional, of not provided then it will attempt to remove access and refresh tokens that matchs
type: string
example:
token: eyJvcmciOiI1ZTIwOTFjNGQ0YWVmY2U2MGMwNGZiOTIiLCJpZCI6ImJlMjlhYjVkODc1OTRhZDJhYTBhNjAwNzFlNzE1ZmQxIiwiaCI6Im11cm11cjY0In0=
client_id: 411f0800957c4a3e81fe181141dbc22a
tags:
- OAuth
operationId: revokeSingleToken
responses:
'200':
description: Succesful response
'/tyk/oauth/revoke_all':
post:
description: revoke all the tokens for a given oauth client
summary: revoke all client's tokens
requestBody:
required: true
content:
application/x-www-form-urlencoded:
schema:
type: object
properties:
client_id:
description: id of oauth client
type: string
client_secret:
description: oauth client secret to ensure that its a valid operation
type: string
example:
client_id: 411f0800957c4a3e81fe181141dbc22a
client_secret: N2Y0YjgzMjctMTEwNi00YWExLWJjM2MtYjg1NWZhM2M1NmNj
tags:
- OAuth
operationId: revokeAllTokens
responses:
'200':
description: Succesful response
'400':
description: Bad request, form malformed or client secret and client id doesn't match
'404':
description: oauth client doesn't have any api related
'/tyk/oauth/refresh/{keyName}':
delete:
summary: Invalidate OAuth refresh token
description: It is possible to invalidate refresh tokens in order to manage OAuth client access more robustly.
tags: