-
Notifications
You must be signed in to change notification settings - Fork 18
/
Copy pathcore-api-schema.yaml
8180 lines (8143 loc) · 290 KB
/
core-api-schema.yaml
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.1.0
# NOTES TO EDITORS:
#
# Guidance for integer types (see https://swagger.io/docs/specification/data-models/data-types/#numbers)
#
# => If a u8, use type: integer, format: int32, minimum: 0, maximum: 255
# => If an i8, use type: integer, format: int32, minimum: -128, maximum: 127 (also, why are you using an i8!?)
# => If a u32:
# => If there's a domain-imposed requirement that fits it within an i32 (2,147,483,647 = 2^31 - 1), with bound B use
# type: integer
# format: int32
# minimum: 0
# maximum: B
# And be sure to validate against B in the code which maps into the type. See EG epoch max length in numerics.rs
# => If not, to be compatible with OAS, we need to put it into an int64:
# type: integer
# format: int64
# minimum: 0
# maximum: 4294967295
# => If an i32, use type: integer, format: int32
# => If a u64:
# => The maximum safe integer in Javascript is (+-)2^53 – 1 = 9,007,199,254,740,991 ~ 9 * 10^15
# To be pragmatic, any numbers outside this range we will choose to represent as strings.
# => So if it's possible for us to assert that: value <= bound B <= 2^53 - 1, then use:
# type: integer, format: int64, minimum: 0, maximum: B
# And be sure to validate against B in the code which maps into the type. See EG epoch max length in numerics.rs
# => If not, use a string instead
# => If an i64:
# => The maximum safe integer in Javascript is (+-)2^53 – 1 = 9,007,199,254,740,991 ~ 9 * 10^15
# To be pragmatic, any numbers outside this range we will choose to represent as strings.
# => So if it's possible for us to assert that: -(2^53 - 1) <= B1 <= value <= B2 <= 2^53 - 1, then use:
# type: integer
# format: int64
# minimum: B1
# maximum: B2
# And be sure to validate against B in the code which maps into the type. See EG epoch max length in numerics.rs
# => If not, use a string instead
# => If something over i64/u64, use type: string
#
# Regardless of the type, specify in the description what the underlying type and bounds are, by starting with something like:
# - An integer between 0 and 10^10, giving
# - A decimal-string-encoded integer between 0 and 2^64 - 1, which
# - A decimal-string-encoded integer between 0 and 10^123, that
#
# Descriptions guidance:
# => For descriptions of encoded types, we follow this pattern: 'The xyz-encoded, abc-encoded xx of the yy'
# EG 'The hex-encoded, SBOR-encoded data' or 'The hex-encoded Blake2b-256 hash of the banana payload'
# => Don't end in a full-stop, unless it is more than 1 sentence, then all sentences should end in a full stop
# => It's not technically valid to have both $ref and description, but it works in ReDocly, so feel free to do it
#
# Naming guidance:
# => Hex-encoded hashes should end _hash
# => Hex-encoded bytes/payload should end _hex and not include _bytes
info:
# Should be the release version, and the release display name
version: 'v1.1.0'
title: 'Radix Core API - Babylon (Anemone)'
license:
name: The Radix License, Version 1.0
url: https://www.radixfoundation.org/licenses/license-v1
x-logo:
url: https://cdn.document360.io/50e78792-5410-4ac9-aa43-4612b4d33953/Images/Documentation/radix-logo-banner.png
href: https://docs.radixdlt.com
description: |
This API is exposed by the Babylon Radix node to give clients access to the Radix Engine, Mempool and State in the node.
The default configuration is intended for use by node-runners on a private network, and is not intended to be exposed publicly.
Very heavy load may impact the node's function. The node exposes a configuration flag which allows disabling certain endpoints
which may be problematic, but monitoring is advised. This configuration parameter is
`api.core.flags.enable_unbounded_endpoints` / `RADIXDLT_CORE_API_FLAGS_ENABLE_UNBOUNDED_ENDPOINTS`.
This API exposes queries against the node's current state (see `/lts/state/` or `/state/`), and streams of transaction history
(under `/lts/stream/` or `/stream`).
If you require queries against snapshots of historical ledger state, you may also wish to consider using the
[Gateway API](https://docs-babylon.radixdlt.com/).
## Integration and forward compatibility guarantees
Integrators (such as exchanges) are recommended to use the `/lts/` endpoints - they have been designed to be clear
and simple for integrators wishing to create and monitor transactions involving fungible transfers to/from accounts.
All endpoints under `/lts/` have high guarantees of forward compatibility in future node versions.
We may add new fields, but existing fields will not be changed. Assuming the integrating code uses a permissive
JSON parser which ignores unknown fields, any additions will not affect existing code.
Other endpoints may be changed with new node versions carrying protocol-updates, although any breaking changes
will be flagged clearly in the corresponding release notes.
All responses may have additional fields added, so clients are advised to use JSON parsers which ignore unknown
fields on JSON objects.
servers:
- url: 'localhost:3333/core'
# See https://redocly.com/docs/api-reference-docs/specification-extensions/x-tag-groups/ for details
x-tagGroups:
- name: Overview
tags:
- SDKs
- SubAPIs
- Concepts
- Construction
- name: Endpoints
tags:
- LTS
- Status
- Transaction
- Mempool
- State
- Stream
tags:
- name: SDKs
x-displayName: SDKs
x-traitTag: true # Don't display endpoints under this tag
description: |
The following SDKs are currently available for the Core API:
- Typescript: [@radixdlt/babylon-core-api-sdk](https://www.npmjs.com/package/@radixdlt/babylon-core-api-sdk)
For other languages, you can use a HTTP client of your choice and code the JSON models yourself.
You could also consider using an Open API generator, but unless you have experience with battling the gremlins in Open API generators,
it may be more trouble than it's worth.
- name: SubAPIs
x-displayName: Sub-APIs
x-traitTag: true # Don't display endpoints under this tag
description: |
The API is split into 6 sub apis:
- **Long Term Support** (`/lts/*`) - For long term support/backward compatible endpoints aimed at integrators such as exchanges.
- **Status** (`/status/*`) - For status and configuration details for the node / engine.
- **Transaction** (`/transaction/*`) - For transaction construction, preview, submission, and monitoring the status of an individual transaction.
- **Mempool** (`/mempool/*`) - For information on the contents of the node's mempool.
- **Current State** (`/state/*`) - For reading the state of entities. At present, we only support reading details from the top of the currently committed ledger.
- **Stream** (`/stream/*`) - For reading the committed transactions.
- name: Concepts
x-displayName: Concepts
x-traitTag: true # Don't display endpoints under this tag
description: |
Interacting with this API effectively may require knowledge about the Radix Babylon Transaction Model and the State Model.
We share some very high-level details below, but please see the [official documentation](http://docs.radixdlt.com) for more details on this.
## Transactions
User transactions are formed of a core "intent", which is then signed by 0+ signatories, before being notarized. The output is called a notarized payload.
It is this notarized transaction payload which is submitted to the network.
For most users, this construction process will generally happen in their Radix Wallet. If you wish to construct transactions programmatically or offline,
you will need to integrate the Radix Engine Toolkit into your application for construction and finalization.
Once submitted, a transaction payload can end up being either rejected or committed. Transactions get rejected if they fail to pass certain criteria at the given time.
A transaction payload can be marked as a:
- **Permanent Rejection** if it is never possible for it to be committed (eg it's statically invalid, or only valid up until epoch 100 and it's now epoch 101)
- **Temporary Rejection** if it still may be possible that the transaction payload could be committed
A given intent typically is only part of one submitted notarized payload, but it's possible for a notary to notarize and submit multiple payloads for the same intent.
The Radix Engine ensures that any intent can only be committed once.
A committed transaction is either committed with an outcome of "Success" or "Failure":
- **Committed Failure** will result in fees being paid up until the failure point, but all other changes will be discarded.
- **Committed Success** will result in all changes being committed.
Only committed transactions appear on ledger. The status of rejected transactions can be read at submission time or from the transaction status endpoint - by virtue of
a rejection cache on the node. This cache is limited in size, so rejected statuses may no longer be tracked after a period of time.
For a more robust handling of transaction rejections, consider running your own Gateway.
## State Model
The Radix Engine State Model can be thought of as a forest of state sub-trees.
A state sub-tree consists of "entities". These entities have an ID, and 0 or more "substates" at keys underneath them.
These substates are typed, and can own other entities, forming a tree of ownership.
Each state sub-tree has a root entity, and a single Bech32M Global Address, with a human-readable-prefix (and prefix byte) matching the root entity type.
As an example, entities include concepts like Components, Packages, Vaults, Resource Managers and Key-Value Stores.
Substates under a component include the Component Struct, Component Data, and Access Rules substates.
- name: Construction
x-displayName: Transaction Construction
x-traitTag: true # Don't display endpoints under this tag
description: |
To construct and submit a transaction using the LTS endpoints:
* Query `/lts/transaction/construction` to retrieve the current epoch (according to your node).
Check also that the `ledger_clock` is close to the current time - this ensures that the node is synced up.
* Make use of the Radix Engine Toolkit to construct the intent, sign/notarize, and compile the notarized transaction.
* You can use `/lts/transaction/submit` to submit the transaction
* Use `/lts/transaction/status` to check the status of the transaction
* Use `/lts/stream/transaction-outcomes` to look up the outcome of the transaction, from its state version
- name: LTS
x-displayName: LTS Endpoints
description: |
For long term support/backward compatible endpoints aimed at integrators such as exchanges.
- name: Status
x-displayName: Status Endpoints
description: |
For status and configuration details for the node / engine.
- name: Transaction
x-displayName: Transaction Endpoints
description: |
For transaction construction, preview, submission, and monitoring the status of an individual transaction.
- name: Mempool
x-displayName: Mempool Endpoints
description: |
For information on the contents of the node's mempool.
- name: State
x-displayName: State Endpoints
description: |
For reading the state of entities. At present, we only support reading details from the top of the currently committed ledger.
- name: Stream
x-displayName: Stream Endpoints
description: To query the transaction or proof stream of the ledger.
paths:
##################################################
# Long Term Support backwards compatible Sub-API #
##################################################
"/lts/transaction/construction":
post:
summary: Get Construction Metadata
description: Returns information necessary to build a transaction
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionConstructionRequest"
responses:
'200':
description: All info needed to build a transaction
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionConstructionResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/lts/transaction/submit":
post:
summary: Submit Transaction
description: |
Submits a notarized transaction to the network. Returns whether the transaction submission was already included in the node's mempool.
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionSubmitRequest"
responses:
'200':
description: Transaction Submit Response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionSubmitResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionSubmitErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionSubmitErrorResponse"
"/lts/transaction/status":
post:
summary: Get Transaction Status
description: |
Shares the node's knowledge of any payloads associated with the given intent hash.
Generally there will be a single payload for a given intent, but it's theoretically possible there may be multiple.
This knowledge is summarised into a status for the intent. This summarised status in the response is likely sufficient
for most clients.
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionStatusRequest"
responses:
'200':
description: Transaction status response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsTransactionStatusResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/lts/state/account-all-fungible-resource-balances":
post:
summary: Get All Account Balances
description: Returns balances for all resources associated with an account
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStateAccountAllFungibleResourceBalancesRequest"
responses:
'200':
description: Account all resource balances response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStateAccountAllFungibleResourceBalancesResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/lts/state/account-fungible-resource-balance":
post:
summary: Get Single Account Balance
description: Returns balance of a single fungible resource in an account
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStateAccountFungibleResourceBalanceRequest"
responses:
'200':
description: Account resource balance response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStateAccountFungibleResourceBalanceResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/lts/state/account-deposit-behaviour":
post:
summary: Get Account Deposit Behaviour
description: Returns deposit behaviour of a single account for multiple resource addresses
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStateAccountDepositBehaviourRequest"
responses:
'200':
description: Account deposit behaviour response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStateAccountDepositBehaviourResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/lts/stream/transaction-outcomes":
post:
summary: Get Transaction Outcomes
description: |
Returns a list of committed transaction outcomes (containing balance changes) from a given state version.
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStreamTransactionOutcomesRequest"
responses:
'200':
description: Paged response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStreamTransactionOutcomesResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/lts/stream/account-transaction-outcomes":
post:
summary: Get Account Transaction Outcomes
description: |
Returns a list of committed transaction outcomes (containing balance changes) from a given state version, filtered to only transactions which involved the given account.
tags:
- LTS
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStreamAccountTransactionOutcomesRequest"
responses:
'200':
description: Paged response
content:
application/json:
schema:
$ref: "#/components/schemas/LtsStreamAccountTransactionOutcomesResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
##################
# Status Sub-API #
##################
"/status/network-configuration":
post:
summary: Get Network Configuration
description: Returns the network configuration of the network the node is connected to.
tags:
- Status
responses:
'200':
description: Network Configuration
content:
application/json:
schema:
$ref: "#/components/schemas/NetworkConfigurationResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/status/network-status":
post:
summary: Get Network Status
description: Returns the current state and status of the node's copy of the ledger.
tags:
- Status
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/NetworkStatusRequest"
responses:
'200':
description: Network Status
content:
application/json:
schema:
$ref: "#/components/schemas/NetworkStatusResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/status/scenarios":
post:
summary: Get Scenarios' results.
description: Get results of test-oriented "Genesis Scenarios" executed on this Network.
tags:
- Status
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/ScenariosRequest"
responses:
'200':
description: Scenarios' results
content:
application/json:
schema:
$ref: "#/components/schemas/ScenariosResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
###################
# Mempool Sub-API #
###################
"/mempool/list":
post:
summary: Get Mempool List
description: Returns the hashes of all the transactions currently in the mempool
tags:
- Mempool
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/MempoolListRequest"
responses:
'200':
description: Mempool List Response
content:
application/json:
schema:
$ref: "#/components/schemas/MempoolListResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/mempool/transaction":
post:
summary: Get Mempool Transaction
description: Returns the payload of a transaction currently in the mempool
tags:
- Mempool
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/MempoolTransactionRequest"
responses:
'200':
description: Mempool Transaction Response
content:
application/json:
schema:
$ref: "#/components/schemas/MempoolTransactionResponse"
'404':
description: Not found error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
#######################
# Transaction Sub-API #
#######################
"/transaction/parse":
post:
summary: Parse Transaction Payload
description: Extracts the contents and hashes of various types of transaction payloads, or sub-payloads.
tags:
- Transaction
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionParseRequest"
responses:
'200':
description: Transaction Parse Response
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionParseResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/transaction/submit":
post:
summary: Transaction Submit
description: |
Submits a notarized transaction to the network. Returns whether the transaction submission was already included in the node's mempool.
tags:
- Transaction
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionSubmitRequest"
responses:
'200':
description: Transaction Submit Response
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionSubmitResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionSubmitErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionSubmitErrorResponse"
"/transaction/status":
post:
summary: Get Transaction Status
description: |
Shares the node's knowledge of any payloads associated with the given intent hash.
Generally there will be a single payload for a given intent, but it's theoretically possible there may be multiple.
This knowledge is summarised into a status for the intent. This summarised status in the response is likely sufficient
for most clients.
tags:
- Transaction
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionStatusRequest"
responses:
'200':
description: Transaction status response
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionStatusResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/transaction/receipt":
post:
summary: Get Transaction Receipt
description: |
Gets the transaction receipt for a committed transaction.
tags:
- Transaction
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionReceiptRequest"
responses:
'200':
description: Committed transaction found response
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionReceiptResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'404':
description: Committed transaction not found response
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/transaction/call-preview":
post:
summary: Scrypto Call Preview
description: |
Preview a scrypto function or method call against the latest network state.
Returns the result of the scrypto function or method call.
tags:
- Transaction
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionCallPreviewRequest"
examples:
method:
summary: A method call example
value: {"target":{"type":"method","component_address":"component_loc1qftacppvmr9ezmekxqpq58en0nk954x0a7jv2zz0hc7qfxlgx4","method_name":"lock_fee"},"arguments":["a120000000000010632d5ec66b050000000000000000000000000000000000000000000000"]}
function:
summary: A function call example
value: {"target":{"type":"function","package_address":"package_loc1q9ufgsc8yh5fkv8kzny3vnp68gkmuytc004k0j8dkwvs0xq76q","blueprint_name":"GumballMachine","function_name":"instantiate_gumball_machine"},"arguments":["a120000000000010632d5ec66b050000000000000000000000000000000000000000000000"]}
responses:
'200':
description: Result of the scrypto function call
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionCallPreviewResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/transaction/preview":
post:
summary: Transaction Preview
description: |
Preview a transaction against the latest network state, and returns the preview receipt.
tags:
- Transaction
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionPreviewRequest"
responses:
'200':
description: Transaction preview response
content:
application/json:
schema:
$ref: "#/components/schemas/TransactionPreviewResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
##################
# Stream Sub-API #
##################
"/stream/proofs":
post:
summary: Stream Proofs
description: |
Returns a stream of proofs committed to the node's ledger.
NOTE: This endpoint may return different results on different nodes:
* Each node may persist different subset of signatures on a given proofs, as long as enough
of the validator set has signed.
* Inside an epoch, different nodes may receive and persist / keep different proofs, subject to
constraints on gaps between proofs.
Proofs during an epoch can also be garbage collected by the node after the fact. Therefore
proofs may disappear from this stream.
Some proofs (such as during genesis and protocol update enactment) are created on a node and don't
include signatures.
This stream accepts four different options in the request:
* All proofs forward (from state version)
* All end-of-epoch proofs (from epoch number)
* All end-of-epoch proofs triggering a protocol update
* All node-injected proofs enacting genesis or a protocol update (for protocol update name, from state version)
The end-of-epoch proofs can be used to "trustlessly" verify the validator set for a given epoch.
By tracking the fact that validators for epoch N sign the next validator set for epoch N + 1,
this chain of proofs can be used to provide proof of the current validator set from a hardcoded
start.
When a validator set is known for a given epoch, this can be used to verify the various transaction
hash trees in the epoch, and to prove other data.
NOTE: This endpoint was built after agreeing the new Radix convention for paged APIs. Its models
therefore follow the new convention, rather than attempting to align with existing loose Core API conventions.
tags:
- Stream
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/StreamProofsRequest"
responses:
'200':
description: Stream proofs response
content:
application/json:
schema:
$ref: "#/components/schemas/StreamProofsResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/StreamProofsErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/StreamProofsErrorResponse"
"/stream/transactions":
post:
summary: Get Committed Transactions
description: |
Returns the list of committed transactions.
tags:
- Stream
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/StreamTransactionsRequest"
responses:
'200':
description: Committed transactions response
content:
application/json:
schema:
$ref: "#/components/schemas/StreamTransactionsResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/StreamTransactionsErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/StreamTransactionsErrorResponse"
#################
# State Sub-API #
#################
"/state/consensus-manager":
post:
summary: Get Consensus Manager Details
description: |
Reads the consensus manager's substate/s from the top of the current ledger.
tags:
- State
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/StateConsensusManagerRequest"
responses:
'200':
description: Current state response
content:
application/json:
schema:
$ref: "#/components/schemas/StateConsensusManagerResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/state/account":
post:
summary: Get Account Details
description: |
Reads the account's substate/s from the top of the current ledger.
Also returns all vaults under the account.
tags:
- State
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/StateAccountRequest"
responses:
'200':
description: Current state response
content:
application/json:
schema:
$ref: "#/components/schemas/StateAccountResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'404':
description: Not found error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/state/component":
post:
summary: Get Component Details
description: |
Reads the component's substate/s from the top of the current ledger.
Also recursively extracts vault balance totals from the component's entity subtree.
tags:
- State
requestBody:
required: true
content:
application/json:
schema:
$ref: "#/components/schemas/StateComponentRequest"
responses:
'200':
description: Current state response
content:
application/json:
schema:
$ref: "#/components/schemas/StateComponentResponse"
'400':
description: Client error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'404':
description: Not found error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
'500':
description: Server error
content:
application/json:
schema:
$ref: "#/components/schemas/BasicErrorResponse"
"/state/validator":
post:
summary: Get Validator Details
description: |