diff --git a/CHANGELOG.md b/CHANGELOG.md index 8bda637c2..11ac2ebf6 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,12 @@ +## 1.7.3 +Release built: 26.09.2024 + +### What’s new? +This release fixes Data Aggregator stall on state version: `139553672` on the `mainnet` network. + +### Database changes +- Removed unique constraint from `IX_account_resource_preference_rule_entry_history_account_enti~` index. + ## 1.7.2 Release built: 17.09.2024 diff --git a/Directory.Build.props b/Directory.Build.props index 78fa575cb..c2523dc43 100644 --- a/Directory.Build.props +++ b/Directory.Build.props @@ -14,7 +14,7 @@ - 1.7.2 + 1.7.3 develop diff --git a/deployment/docker-compose.yml b/deployment/docker-compose.yml index b5c5d1b99..ea6246525 100644 --- a/deployment/docker-compose.yml +++ b/deployment/docker-compose.yml @@ -51,13 +51,13 @@ services: retries: 3 database_migrations: # This is the base -- the _image and _built containers are defined below - image: "radixdlt/babylon-ng-database-migrations:v1.7.2" + image: "radixdlt/babylon-ng-database-migrations:v1.7.3" profiles: ["NONE"] environment: ConnectionStrings__NetworkGatewayMigrations: "Host=postgres_db:5432;Database=${POSTGRES_DB_NAME};Username=${POSTGRES_SUPERUSER};Password=${POSTGRES_SUPERUSER_PASSWORD}" data_aggregator: # This is the base -- the _image and _built containers are defined below - image: "radixdlt/babylon-ng-data-aggregator:v1.7.2" + image: "radixdlt/babylon-ng-data-aggregator:v1.7.3" profiles: ["NONE"] deploy: restart_policy: @@ -97,7 +97,7 @@ services: - ./data-aggregator-fixed-configuration.json:/home/radixdlt/network-gateway/config.json gateway_api: # This is the base -- the _image and _built containers are defined below - image: "radixdlt/babylon-ng-gateway-api:v1.7.2" + image: "radixdlt/babylon-ng-gateway-api:v1.7.3" profiles: ["NONE"] ports: - "127.0.0.1:5308:8080" # This allows you to connect to the API at http://localhost:5308 diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml b/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml index 2f3d34463..6a621e4e5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml +++ b/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml @@ -1,6 +1,6 @@ openapi: 3.0.0 info: - version: v1.7.2 + version: v1.7.3 title: Radix Gateway API - Babylon license: name: The Radix License, Version 1.0 diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/ExtensionsApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/ExtensionsApi.cs index 5aa24c847..74b778f6e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/ExtensionsApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/ExtensionsApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs index ca09c3004..726181d7e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs index 45a5b0a43..cc7fe11ee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs index a4df74689..46bce418b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs index 14d81ac9d..fdc5d3664 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs index 5c0283205..ed160eaae 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs index fb7bcbf83..1fd7452ab 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs index 4adc75d3a..5cd467c4b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs index 1ad68fba3..bbe6812ca 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs index 3b48b0a82..1c8631ea2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs index 26ab9b853..ddda20b7f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -591,7 +591,7 @@ public static string ToDebugReport() string report = "C# SDK (RadixDlt.NetworkGateway.GatewayApiSdk) Debug Report:\n"; report += " OS: " + System.Environment.OSVersion + "\n"; report += " .NET Framework Version: " + System.Environment.Version + "\n"; - report += " Version of the API: v1.7.2\n"; + report += " Version of the API: v1.7.3\n"; report += " SDK Package Version: 1.0.0\n"; return report; diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs index 5481ac210..d7b896b94 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs index 102cc0c36..a0014d26a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs index c650289f9..f35798547 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs index 2916eabcc..48aede44b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs index 004dde565..dfe44b3b4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs index 42dd785f3..a409a3793 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs index 1f08deb70..3c2cbc6f3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs index 50f5698a3..e2ab874de 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs index 37d454971..4683dd239 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs index a8de6b12f..77cfdb4cd 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs index 8beb581b0..a6f4aedb7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs index d9acc3c56..e46ae9bfd 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs index 636cbe72e..ed8d1684a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorBadgeType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorBadgeType.cs index ef564e735..c78a2f928 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorBadgeType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorBadgeType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollection.cs index 9d437d2b6..01463f8d3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollectionAllOf.cs index d3b727f23..72d11068b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadge.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadge.cs index ce09b1db3..26b42d600 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadge.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadge.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadgeAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadgeAllOf.cs index 5ddacba5f..6c26bf868 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadgeAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsNonFungibleBadgeAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadge.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadge.cs index 40941b5c9..295125065 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadge.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadge.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadgeAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadgeAllOf.cs index d75f2169b..f8f3962f2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadgeAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResourceBadgeAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResponseItem.cs index 9e64118b3..0f3207487 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountAuthorizedDepositorsResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDefaultDepositRule.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDefaultDepositRule.cs index 950fc86bb..6943a7c1a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDefaultDepositRule.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDefaultDepositRule.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactors.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactors.cs index f6948558f..3e2edcad6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactors.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactors.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactorsResourceSpecificDetailsItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactorsResourceSpecificDetailsItem.cs index d7f7ea6ab..c65d880a1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactorsResourceSpecificDetailsItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationDecidingFactorsResourceSpecificDetailsItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadge.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadge.cs index 98d7af31f..ff70ebe45 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadge.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadge.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadgeAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadgeAllOf.cs index 51df6fff5..5c1366d52 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadgeAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationNonFungibleBadgeAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequest.cs index 20457eef3..f30bad055 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequestAllOf.cs index bd24debfb..58e4c8d63 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceBadge.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceBadge.cs index 27d48af6b..7af92e2a4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceBadge.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceBadge.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceSpecificBehaviourItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceSpecificBehaviourItem.cs index 967cc3bba..ff1543b01 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceSpecificBehaviourItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResourceSpecificBehaviourItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponse.cs index 1f659447c..c73d75080 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponseAllOf.cs index 8df285eb5..0a94f8e8d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountDepositPreValidationResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerAddress.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerAddress.cs index 35f677233..689b20dde 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerAddress.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerAddress.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerNotFoundError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerNotFoundError.cs index 50e3488d8..e939aab23 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerNotFoundError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerNotFoundError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollection.cs index 6aac7eaa6..ab70360db 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionAllOf.cs index cc97eca56..82cd2a40a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItem.cs index ec3937b96..d8b35e0d2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungible.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungible.cs index e020d787c..338300dd7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungible.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungible.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungibleAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungibleAllOf.cs index 39e3c86ce..de4ed789d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungibleAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemFungibleAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungible.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungible.cs index 2dbe5beb5..4f8141be5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungible.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungible.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungibleAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungibleAllOf.cs index 2f45efe2c..7058771f2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungibleAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemNonFungibleAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemType.cs index 48d08a17d..4eb4b3317 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountLockerVaultCollectionItemType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferenceRule.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferenceRule.cs index 263c097b1..b281910a9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferenceRule.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferenceRule.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollection.cs index bab320815..0cd8660a3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollectionAllOf.cs index 38947589b..153253532 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesResponseItem.cs index b8de86534..de084d8eb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AccountResourcePreferencesResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs index 62d7df515..c3509a8aa 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintMethodRoyalty.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintMethodRoyalty.cs index db649bdbc..0549dbb94 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintMethodRoyalty.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintMethodRoyalty.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintRoyaltyConfig.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintRoyaltyConfig.cs index af92c034b..3d0d84fa8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintRoyaltyConfig.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/BlueprintRoyaltyConfig.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs index 18ec30641..27a065647 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs index 949bb3432..157752a41 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs index 3a5b0fa0f..e814cd796 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs index cd1cca16a..70aa7353e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentMethodRoyalty.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentMethodRoyalty.cs index 991884f8c..69d717f98 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentMethodRoyalty.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentMethodRoyalty.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentRoyaltyConfig.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentRoyaltyConfig.cs index 62dff69a9..0e36f6e84 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentRoyaltyConfig.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentRoyaltyConfig.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs index 08097d6c4..bae90616c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs index ee393c43d..36fe7b822 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs index 086fa0672..3e5806098 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs index e1a5775ab..189797375 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs index fee49e9f6..b16c25635 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs index f90b0f721..dadd59942 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs index 3c7c86228..b8dc809b8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollection.cs index d8491164d..3f5ed35f5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionAllOf.cs index b2d627f95..f01793ec6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionItem.cs index 63c115c6f..e75661730 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntitySchemaCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs index d5a205920..97d2409cc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs index ec34592de..b68b35b70 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs index 6a7fc74b3..2e4b2e369 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs index 2c394d1cf..699b534da 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs index 765cd27fd..1d1da2b17 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs index 8bfb38ef4..9ae32e4a2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs index 42e5629fe..da84a9a28 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs index 09efeefd0..fa8a7a8c6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs index 0b68c935e..8731c23e3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs index 0321e232e..6c0d12122 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs index d5c02c274..c0e86f6df 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs index 205e91b97..a6045129c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs index c9d859929..2343fd0b5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs index 2d62fff6e..8e26acf4d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs index ead42f854..f53d03aa5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs index 467ff0ddc..e4d13d6ad 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs index 8441a54cd..bafa993a0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs index 52de04da5..438cbff7d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs index 7743fdac8..98ffc75a7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs index c507902be..e2da89540 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs index f67723aa9..9ba1cd404 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs index 224ee5abb..82177a9fb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs index c15dd428c..68399a4e8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs index d2e4b26f3..958c458ee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs index 288242183..64000e988 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs index 2101cfb86..dac6f3dee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs index 3197c8238..52ced7e07 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs index 7a0c85aab..dc3f6e132 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs index c66beacec..aee5b010b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs index 7dd9593bc..7c38a8245 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs index 04f49eed1..61702834f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs index 05be4fd6d..0b7e6f149 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs index cef96560a..8954c44af 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs index ff6039033..3dba92350 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs index a811144bb..8f8b8d89d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs index 7dd7d0e37..d0eff627c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs index 160fa6bb4..2c7755101 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs index f130960b2..368032759 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs index 11cd9d9a3..08a18a907 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs index aa5f6f14a..d649e0324 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs index b084a1222..764d5210a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValueAllOf.cs index 770760e19..76875fac4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs index 1706e334b..62c6f3a3a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValueAllOf.cs index 903b7ee31..f02ae2148 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs index 7c34c6192..0992fa98e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs index 3991589a2..709b426f1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs index 6f0c3dbf2..d78e67053 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs index c6d117be6..6a8ff3274 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs index 538a4bc63..95131514e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs index 9a180889b..1dcfdcb66 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs index 4ed6690dd..4d3e1859d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs index 7b8b4d6ce..bb5b47116 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs index 9ac549e47..f110e4f77 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs index 343605dd7..f7caaf27b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs index 4dca48058..3b902be2c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs index 438503209..e8a4220c7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs index 58496d0cf..9970a25c1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs index 65b1da594..2394aae71 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs index 40af2278e..50f6115e9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs index 06a2938ef..9882799fe 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs index 15820663d..6273e5fcc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs index 866f3e173..2a9abf0d0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs index cde130e3e..01e47a02d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs index ee112462d..fe56c5c3d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs index ff988afb5..3fc550a6d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs index 5def4db70..2ac4d1ed5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs index 8178f596f..674140c27 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs index 3c367bde7..5f84fe9a2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs index 0ab4b83ae..60ba4032f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs index be7e10c21..b7b7268df 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs index 25d03ee91..6e8066ced 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs index c20d6543e..c42aa380a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs index 6f31f8aa3..b7270b187 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs index fb60d61ac..0ff404b3f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs index cd1ce03e9..125fcadbe 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValue.cs index 61d021d95..09f815bf7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValueAllOf.cs index 4f626d3af..aa29a1f16 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccessControllerRecoveryBadgeValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccountOwnerBadgeValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccountOwnerBadgeValue.cs index d8f4204fe..143bdfc43 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccountOwnerBadgeValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceAccountOwnerBadgeValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceDetails.cs index 78ab62556..3a53e727f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceEd25519SignatureResourceValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceEd25519SignatureResourceValue.cs index 593b42c20..aac294f30 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceEd25519SignatureResourceValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceEd25519SignatureResourceValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceGlobalCallerResourceValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceGlobalCallerResourceValue.cs index 83fcb4d40..3e15c56b8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceGlobalCallerResourceValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceGlobalCallerResourceValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceIdentityOwnerBadgeValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceIdentityOwnerBadgeValue.cs index 536b2cab0..cc9e9924e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceIdentityOwnerBadgeValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceIdentityOwnerBadgeValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceKind.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceKind.cs index 8784851a3..3d6fd9a10 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceKind.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceKind.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceMultiResourcePoolUnitValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceMultiResourcePoolUnitValue.cs index ad976a74a..021230146 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceMultiResourcePoolUnitValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceMultiResourcePoolUnitValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValue.cs index 2d042cf5f..c2fd79753 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValueAllOf.cs index 68273704b..a8ea3c002 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceOneResourcePoolUnitValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOfDirectCallerResourceValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOfDirectCallerResourceValue.cs index 926843ff0..6f2c7b128 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOfDirectCallerResourceValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOfDirectCallerResourceValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOwnerBadgeValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOwnerBadgeValue.cs index ff5b90d9a..e0a263565 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOwnerBadgeValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourcePackageOwnerBadgeValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceRedemptionValueItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceRedemptionValueItem.cs index 6fdc2ad92..26dc04cf5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceRedemptionValueItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceRedemptionValueItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSecp256k1SignatureResourceValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSecp256k1SignatureResourceValue.cs index e50ea7818..fad44ff80 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSecp256k1SignatureResourceValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSecp256k1SignatureResourceValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSystemExecutionResourceValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSystemExecutionResourceValue.cs index 9d198ff63..168831c02 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSystemExecutionResourceValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceSystemExecutionResourceValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceTwoResourcePoolUnitValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceTwoResourcePoolUnitValue.cs index 415e68c03..1e3690b01 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceTwoResourcePoolUnitValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceTwoResourcePoolUnitValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValue.cs index 51a0334ba..8190becc2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValueAllOf.cs index fdc8772c1..7591dedf0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorClaimNFTValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValue.cs index 28c2e1e71..4fcd1d4ae 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValueAllOf.cs index d6cd9265f..5d08d8838 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorLiquidStakeUnitValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorOwnerBadgeValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorOwnerBadgeValue.cs index 9271b2dc2..c320aff49 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorOwnerBadgeValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceValidatorOwnerBadgeValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceXrdValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceXrdValue.cs index 75dc77df0..822eca8c4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceXrdValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NativeResourceXrdValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs index 05bef44c5..9140307c3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs index 98fb03252..cdd8050ef 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs index 2d12ce6fc..27b495b0a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs index 5eb956ea9..854504532 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs index bd1b4e93c..a37f529c1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs index 20b2f459b..abd8d795c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs index cdee1bc33..c449eea9f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs index 10c0e3ffc..4a261f572 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs index 8fd96f3ff..83dc5640b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs index ab1725d85..569efa03d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs index 24aacd18e..59dfdd142 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs index 6a7a53e59..4fb69d287 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs index 55c6493f7..2a68a2f9c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs index 885704aff..ac5006a6b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs index 1ccb48853..97d22ee9b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs index b810d95ba..e698418ee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs index 25a2f60e1..8f654ccbb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs index 07258f0ed..f013305d7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs index d1a1ff80b..0c19f6544 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs index 69eab4578..5180e9768 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs index eba66b931..c305c4a02 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollection.cs index f5c94eac1..2cf30f99e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionAllOf.cs index d103b9abb..cd3e9d54b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionItem.cs index fc0e9250d..87219a048 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageBlueprintCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollection.cs index 80edbe5aa..4de981177 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionAllOf.cs index c2d70093c..d4bb391bc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs index e95816c4f..8889ada38 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs index 63fba6867..b16eb923e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs index bee2ed06c..c82cc0fa4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs index 56e3fd8de..b8c643e11 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs index 8f07f9060..68466826c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs index f0ea7f563..a293c209a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs index 18c13cc5d..b0fe2a871 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs index 6850ac609..70e86aa64 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs index 2b4c1e365..541e6ce32 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs index 26c96a997..036cc4439 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs index 893c09144..0667020de 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs index 19a5095ba..2422d5ced 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs index 0d4585a71..3a8465698 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs index 4d966feaf..b56749c30 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs index cba548cb1..214e14cae 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs index 0a557f8d2..182480de7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs index d6c064c75..11cd15da6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs index 868e9fe98..a0d181543 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs index 4aece5c84..43bc7b644 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs index 14dd1ae9b..2e6adf36e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs index 87df80330..766807b77 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs index 47fe7c738..bede76582 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs index 370bd82d1..e57d1f072 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs index d246eca51..070ee9d45 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReferenceAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReferenceAllOf.cs index 85b81bd1e..fc5ea4555 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReferenceAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReferenceAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs index 73188f33e..29ffbfed5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs index bb76ec90e..2c064c994 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs index aa85c3791..362517545 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs index d73e253c2..6be66041c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs index 3daa2fc05..30b416374 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs index 4361f4bd6..c4c8465f6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs index 945b0f5f5..0117dae53 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs index dd75d7e41..f24dc5d73 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs index 3c78ac060..19110a1c2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs index ffe387d73..af9db93c0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs index 027e0dd06..53b969674 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs index 2c4fa0096..ed88b7628 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs index 74ae455df..332ab0196 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs index 6c2516b35..a1e9e6a92 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs index 34be68cf1..5fcbf56e0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs index 810325dab..16eb7cc8a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs index ae20e4727..c2350b463 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs index a66a8fd45..a18e06263 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs index 01992c62a..0b72714d8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs index 58cdeb5ac..83cce246d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollection.cs index b729c8c06..cf27d019d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionAllOf.cs index 299f72fa8..ba73c4037 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionFungibleResourceItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionFungibleResourceItem.cs index 29ebcdff3..c1db70247 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionFungibleResourceItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionFungibleResourceItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionItem.cs index 6fdc4d14e..26c5d1876 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItem.cs index 00c3d3463..fe2ea857a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItemAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItemAllOf.cs index 1036bc6c3..fccf220b1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItemAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersCollectionNonFungibleResourceItemAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequest.cs index 383a39de7..090b64791 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequestAllOf.cs index 3f3ecc35a..2711bb874 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResourceType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResourceType.cs index 14a240f2d..4eb548878 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResourceType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResourceType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResponse.cs index c5ce28d92..d7f24c135 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceHoldersResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs index 1e81395f9..e07921709 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs index 9af5301c0..eb8256e32 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs index ef87bd1da..cb7695599 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoyaltyAmount.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoyaltyAmount.cs index b4c11edc7..d994ed307 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoyaltyAmount.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoyaltyAmount.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs index 5b680c7f1..9ffd2bcb5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageRequest.cs index 37f48c527..125ccc51c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageResponse.cs index 1907270b8..dc6c9f08e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountAuthorizedDepositorsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsRequest.cs index e58c9fcbe..aae89623c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsResponse.cs index 62d19cf7d..33326608a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockerPageVaultsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequest.cs index 3a053f6af..0a81ab82b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequestAllOf.cs index 21084bdd9..807562187 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponse.cs index 031559210..0de475eda 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseAllOf.cs index e32102989..c9b664cc9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItem.cs index cf0804996..b918f7717 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItemAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItemAllOf.cs index a9e528698..a657be0e1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItemAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountLockersTouchedAtResponseItemAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequest.cs index 7715fadf2..66ee364ed 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequestAllOf.cs index 842be08da..cb7705d61 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageResponse.cs index 7bf76fef7..ea5ecfc2c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateAccountResourcePreferencesPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs index 83e4a68f9..d4670be43 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs index 6f373d12f..90423926f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs index 49b2ba240..435818f18 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs index 11ae4b520..d80581f49 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs index 2e812a154..86278fda3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs index 960cdf63e..c53eee8f3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs index c61317f7c..ee737de30 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs index 219c243e1..e08cc2a2c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs index ac9ea4b0e..4d6b046a6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs index f9ad0d3ae..259b3d5f0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs index 25a6441ee..a5ae3dd27 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs index 31ffc9228..cc16ee7ea 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs index 842bfadff..408bf5182 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs index 7d6c21960..b957a07b1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs index ac58b3bac..9f909ed5d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs index 27fa2f01e..c012fb158 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs index 40dc8160b..bf57cf250 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs index 06378d4a7..513213a2b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs index f7aaee8a5..00ec6e2da 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs index f100c3a2f..c2f19d0df 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs index 849dd44d6..555ed97ee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs index 3ca914fd2..57b528da7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs index c1464998d..16acbfecd 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs index 5b3d20543..5140616ae 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs index 9a6f8a584..262fe939e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs index 19b86b210..01c373d94 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs index 197540c81..0d87c06a2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs index 3c7f126fc..951593b23 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs index 3a011c7ee..16cb07410 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs index 296e0b9b8..34e17f5dd 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs index 05dff3f94..6304ca16d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs index bdd551420..cf3beca1e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs index ba4f89317..b6e2f57e3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs index 7b1e946fb..3f2577a41 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs index 4413f7f4a..62dad3680 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs index d86815ec8..59cd8a913 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs index a8a57b686..74f716f5f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs index b1313a7ab..9a36f457a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs index f678dbc8e..018f529b8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs index af5f0645d..723779949 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs index d0357020a..b5d737115 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs index 24d945342..eef0886a5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageRequest.cs index 7f37286b2..8ff0c9c76 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageResponse.cs index e3726c053..af1cc0cf0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntitySchemaPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs index b6ad1278b..150a97c51 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs index 20a6a912e..f51cbceb9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs index f9829de73..2a3865a6e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs index 2e0375cc1..0658641a5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs index c89218eef..dab703b4c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs index 09f08577d..2f264c2c6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs index 9b77c7c31..8cc18e0ee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs index 09e12fb28..1ff4a8359 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs index 32c8423e9..1f1aebe2c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs index 29dd9e5bd..d3ed25c5a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs index b598c665e..da36a260a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs index 1560dc516..f15e1c2ff 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs index 6d55003c4..ca25b8db3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs index 50051df5b..fc9540bd8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs index 8535fc412..0229c5454 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs index 9984c7e03..ca53f4ce0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs index 566c191bd..da030803d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs index 1c8e0b592..dad0ed8e7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs index 82d8f7ed3..f5b28897b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs index 70e753638..a2a527172 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs index 8589dc45d..fee9bbafd 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs index f8ff19a27..bb9786661 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs index be1bedb79..36e1248d4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs index ec3f8e8c9..d1e5657e6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs index ab470eb0b..2f1b221b4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequest.cs index c1e055dc5..4db03329b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequestAllOf.cs index 2571ef1d1..45d75a247 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageResponse.cs index 82edf453d..ce4e9b3be 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageBlueprintPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageRequest.cs index 1a2fa6b1f..b092ce377 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageResponse.cs index 44ea83f8b..711de5cb5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StatePackageCodePageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs index a79478681..709aa82e0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs index cd700778d..61960cc27 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs index 3df6da2d6..a299e537e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs index b1747f1ef..6d7e2bb6a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs index fd68c3a8e..2fd40c778 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs index 90fc883ae..902ad9087 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs index cda8fe15e..024434c2e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs index e368d451d..5389709b5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs index 66239ebe6..89cd6f1fc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs index 4e707ea07..2fba8bf4a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionAccountDepositPreValidationAuthorizedDepositorBadge.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionAccountDepositPreValidationAuthorizedDepositorBadge.cs index 55888009f..40cedcb0e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionAccountDepositPreValidationAuthorizedDepositorBadge.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionAccountDepositPreValidationAuthorizedDepositorBadge.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs index 732b7f175..6d7ec9ccb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs index a110aad76..28e331402 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs index f9c9effc3..62bbaa861 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs index 9a71a0e9a..a765fd8cc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs index b0ab6775c..a0556d257 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs index 116a5ad2f..38d19ac1f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs index 5d5d5a057..0c8f8d608 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs index 9f31c3f73..fc481a886 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs index 75c1bf3a1..baa94d39d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs index b69523c82..65376dad6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs index cdeb1f973..93d84a311 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs index 7c0a8ff70..71b2bc3a2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs index 600a41e74..a267653ab 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs index 930f28322..c702b03b1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs index e9a745c50..9e96c1951 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewOptIns.cs index 466dfe316..ad3dfc3d3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs index f0a4a1196..73aea5d13 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs index aabc16bc1..a857dfb9a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs index 05d88708a..5de844eb2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs index 4a1a74107..ff08d997e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs index 3b6673086..266467630 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs index 302db47cf..3d6262d30 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs index 5a3f3cf4f..c979117c6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs index 18ae881da..8af9c6172 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs index 802b114c3..591023b40 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs index ebb3ff64d..95c311989 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs index d0951954b..6da04e7d8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs index 4291693e4..34dd1adf0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs index 6107b6fcd..30bf73ef8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappOnLedgerDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappOnLedgerDetails.cs index 03d9123df..eaba84ffe 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappOnLedgerDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappOnLedgerDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollection.cs index b5518d822..7d9ec15f5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionAllOf.cs index e28e0fcc0..5d6ece3f2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionItem.cs index cb74f0035..07c5879d2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedDappsCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollection.cs index c634870d4..4052d0b6a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionAllOf.cs index f1c89d67c..e62094d69 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionItem.cs index fb212a5f7..69f722455 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TwoWayLinkedEntitiesCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs index cd206224d..99305fc2c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs index 692911933..662b7efce 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs index e598ef785..d4f457d83 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs index 43c8f09a3..650cf4e01 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs index d8cfcbf73..47ffaf611 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs index 634463406..1ef02152f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs index 752d35208..9687afc29 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs index 2b28378f9..f2cd84e06 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs index 42bee0a5f..5c1376ada 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs index 5952a9323..c87e84830 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs index cc5a696c0..e739c2827 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs index cbeb8f570..400ff1723 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs index 64281aca1..659f57863 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs index 28520d074..07e9ec90c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs index 052b23dac..304ecec79 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.7.2 + * The version of the OpenAPI document: v1.7.3 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs index 667f62362..19a9619c3 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs @@ -409,8 +409,7 @@ private static void HookupDefinitions(ModelBuilder modelBuilder) modelBuilder .Entity() - .HasIndex(e => new { e.AccountLockerDefinitionId, e.FromStateVersion }) - .IsUnique(); + .HasIndex(e => new { e.AccountLockerDefinitionId, e.FromStateVersion }); } private static void HookupHistory(ModelBuilder modelBuilder) diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240926150449_RemoveUniqueConstrainFromAccountLockerIndex.Designer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240926150449_RemoveUniqueConstrainFromAccountLockerIndex.Designer.cs new file mode 100644 index 000000000..b0247634a --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240926150449_RemoveUniqueConstrainFromAccountLockerIndex.Designer.cs @@ -0,0 +1,2921 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +// +using System; +using System.Collections.Generic; +using System.Numerics; +using Microsoft.EntityFrameworkCore; +using Microsoft.EntityFrameworkCore.Infrastructure; +using Microsoft.EntityFrameworkCore.Migrations; +using Microsoft.EntityFrameworkCore.Storage.ValueConversion; +using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; +using RadixDlt.NetworkGateway.Abstractions.Model; +using RadixDlt.NetworkGateway.Abstractions.StandardMetadata; +using RadixDlt.NetworkGateway.PostgresIntegration; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; + +#nullable disable + +namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations +{ + [DbContext(typeof(MigrationsDbContext))] + [Migration("20240926150449_RemoveUniqueConstrainFromAccountLockerIndex")] + partial class RemoveUniqueConstrainFromAccountLockerIndex + { + /// + protected override void BuildTargetModel(ModelBuilder modelBuilder) + { +#pragma warning disable 612, 618 + modelBuilder + .HasAnnotation("ProductVersion", "8.0.2") + .HasAnnotation("Relational:MaxIdentifierLength", 63); + + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "authorized_depositor_badge_type", new[] { "resource", "non_fungible" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_relationship", new[] { "component_to_instantiating_package", "vault_to_resource", "royalty_vault_of_component", "validator_to_stake_vault", "validator_to_pending_xrd_withdraw_vault", "validator_to_locked_owner_stake_unit_vault", "validator_to_pending_owner_stake_unit_unlock_vault", "stake_unit_of_validator", "claim_token_of_validator", "account_locker_of_locker", "account_locker_of_account", "resource_pool_to_unit_resource", "resource_pool_to_resource", "resource_pool_to_resource_vault", "unit_resource_of_resource_pool", "resource_vault_of_resource_pool", "access_controller_to_recovery_badge", "recovery_badge_of_access_controller" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker", "global_account_locker" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_manifest_class", new[] { "general", "transfer", "validator_stake", "validator_unstake", "validator_claim", "account_deposit_settings_update", "pool_contribution", "pool_redemption" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from", "account_owner_method_call", "badge_presented" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity", "manifest_class", "event_global_emitter" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update", "flash" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "non_fungible_id_type", new[] { "string", "integer", "bytes", "ruid" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "package_vm_type", new[] { "native", "scrypto_v1" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_intent_ledger_status", new[] { "unknown", "committed", "commit_pending", "permanent_rejection", "possible_to_commit", "likely_but_not_certain_rejection" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_payload_ledger_status", new[] { "unknown", "committed", "commit_pending", "clashing_commit", "permanently_rejected", "transiently_accepted", "transiently_rejected" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "public_key_type", new[] { "ecdsa_secp256k1", "eddsa_ed25519" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "resource_type", new[] { "fungible", "non_fungible" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "sbor_type_kind", new[] { "well_known", "schema_local" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "standard_metadata_key", new[] { "dapp_account_type", "dapp_definition", "dapp_definitions", "dapp_claimed_websites", "dapp_claimed_entities", "dapp_account_locker" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "state_type", new[] { "json", "sbor" }); + NpgsqlModelBuilderExtensions.UseIdentityByDefaultColumns(modelBuilder); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountAuthorizedDepositorAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountEntityId") + .HasColumnType("bigint") + .HasColumnName("account_entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("AccountEntityId", "FromStateVersion"); + + b.ToTable("account_authorized_depositor_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountAuthorizedDepositorEntryHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountEntityId") + .HasColumnType("bigint") + .HasColumnName("account_entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("discriminator") + .HasColumnType("authorized_depositor_badge_type"); + + b.HasKey("Id"); + + b.HasIndex("AccountEntityId", "FromStateVersion"); + + b.ToTable("account_authorized_depositor_entry_history"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountDefaultDepositRuleHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountEntityId") + .HasColumnType("bigint") + .HasColumnName("account_entity_id"); + + b.Property("DefaultDepositRule") + .HasColumnType("account_default_deposit_rule") + .HasColumnName("default_deposit_rule"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("AccountEntityId", "FromStateVersion"); + + b.ToTable("account_default_deposit_rule_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountLockerEntryDefinition", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountEntityId") + .HasColumnType("bigint") + .HasColumnName("account_entity_id"); + + b.Property("AccountLockerEntityId") + .HasColumnType("bigint") + .HasColumnName("account_locker_entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("KeyValueStoreEntityId") + .HasColumnType("bigint") + .HasColumnName("key_value_store_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("AccountLockerEntityId", "AccountEntityId") + .IsUnique(); + + b.ToTable("account_locker_entry_definition"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountLockerEntryResourceVaultDefinition", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountLockerDefinitionId") + .HasColumnType("bigint") + .HasColumnName("account_locker_definition_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.Property("VaultEntityId") + .HasColumnType("bigint") + .HasColumnName("vault_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("AccountLockerDefinitionId", "FromStateVersion"); + + b.ToTable("account_locker_entry_resource_vault_definition"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountLockerEntryTouchHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountLockerDefinitionId") + .HasColumnType("bigint") + .HasColumnName("account_locker_definition_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("AccountLockerDefinitionId", "FromStateVersion"); + + b.ToTable("account_locker_entry_touch_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountResourcePreferenceRuleAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountEntityId") + .HasColumnType("bigint") + .HasColumnName("account_entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("AccountEntityId", "FromStateVersion"); + + b.ToTable("account_resource_preference_rule_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountResourcePreferenceRuleEntryHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AccountEntityId") + .HasColumnType("bigint") + .HasColumnName("account_entity_id"); + + b.Property("AccountResourcePreferenceRule") + .HasColumnType("account_resource_preference_rule") + .HasColumnName("account_resource_preference_rule"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("AccountEntityId", "ResourceEntityId", "FromStateVersion"); + + b.ToTable("account_resource_preference_rule_entry_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("component_method_royalty_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsLocked") + .HasColumnType("boolean") + .HasColumnName("is_locked"); + + b.Property("MethodName") + .IsRequired() + .HasColumnType("text") + .HasColumnName("method_name"); + + b.Property("RoyaltyAmount") + .HasColumnType("jsonb") + .HasColumnName("royalty_amount"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.HasIndex("EntityId", "MethodName", "FromStateVersion"); + + b.ToTable("component_method_royalty_entry_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("Address") + .IsRequired() + .HasColumnType("text") + .HasColumnName("address"); + + b.Property>("AncestorIds") + .HasColumnType("bigint[]") + .HasColumnName("ancestor_ids"); + + b.Property>("CorrelatedEntityIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("correlated_entity_ids"); + + b.Property>("CorrelatedEntityRelationships") + .IsRequired() + .HasColumnType("entity_relationship[]") + .HasColumnName("correlated_entity_relationships"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("GlobalAncestorId") + .HasColumnType("bigint") + .HasColumnName("global_ancestor_id"); + + b.Property("IsGlobal") + .HasColumnType("boolean") + .HasColumnName("is_global"); + + b.Property("OwnerAncestorId") + .HasColumnType("bigint") + .HasColumnName("owner_ancestor_id"); + + b.Property("ParentAncestorId") + .HasColumnType("bigint") + .HasColumnName("parent_ancestor_id"); + + b.Property("discriminator") + .HasColumnType("entity_type"); + + b.HasKey("Id"); + + b.HasIndex("Address") + .IsUnique(); + + b.HasIndex("FromStateVersion") + .HasFilter("discriminator = 'global_validator'"); + + b.ToTable("entities"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property>("MetadataIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("metadata_ids"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("entity_metadata_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("IsLocked") + .HasColumnType("boolean") + .HasColumnName("is_locked"); + + b.Property("Key") + .IsRequired() + .HasColumnType("text") + .HasColumnName("key"); + + b.Property("Value") + .HasColumnType("bytea") + .HasColumnName("value"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "Key", "FromStateVersion"); + + b.ToTable("entity_metadata_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property>("FungibleResourceEntityIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("fungible_resource_entity_ids"); + + b.Property>("FungibleResourceSignificantUpdateStateVersions") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("fungible_resource_significant_update_state_versions"); + + b.Property>("NonFungibleResourceEntityIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("non_fungible_resource_entity_ids"); + + b.Property>("NonFungibleResourceSignificantUpdateStateVersions") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("non_fungible_resource_significant_update_state_versions"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("entity_resource_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.Property("discriminator") + .HasColumnType("resource_type"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); + + b.ToTable("entity_resource_aggregated_vaults_history"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceVaultAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.Property>("VaultEntityIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("vault_entity_ids"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); + + b.ToTable("entity_resource_vault_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("OwnerRoleId") + .HasColumnType("bigint") + .HasColumnName("owner_role_id"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("entity_role_assignments_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsEntryHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("KeyModule") + .HasColumnType("module_id") + .HasColumnName("key_module"); + + b.Property("KeyRole") + .IsRequired() + .HasColumnType("text") + .HasColumnName("key_role"); + + b.Property("RoleAssignments") + .HasColumnType("jsonb") + .HasColumnName("role_assignments"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "KeyRole", "KeyModule", "FromStateVersion"); + + b.ToTable("entity_role_assignments_entry_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsOwnerRoleHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("RoleAssignments") + .IsRequired() + .HasColumnType("jsonb") + .HasColumnName("role_assignments"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("entity_role_assignments_owner_role_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("GlobalEntityId") + .HasColumnType("bigint") + .HasColumnName("global_entity_id"); + + b.Property("OwnerEntityId") + .HasColumnType("bigint") + .HasColumnName("owner_entity_id"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.Property("VaultEntityId") + .HasColumnType("bigint") + .HasColumnName("vault_entity_id"); + + b.Property("discriminator") + .HasColumnType("resource_type"); + + b.HasKey("Id"); + + b.HasIndex("GlobalEntityId", "FromStateVersion") + .HasFilter("is_royalty_vault = true"); + + b.HasIndex("OwnerEntityId", "FromStateVersion") + .HasFilter("is_royalty_vault = true"); + + b.HasIndex("VaultEntityId", "FromStateVersion"); + + b.HasIndex("GlobalEntityId", "VaultEntityId", "FromStateVersion"); + + b.HasIndex("Id", "ResourceEntityId", "FromStateVersion"); + + b.HasIndex("OwnerEntityId", "VaultEntityId", "FromStateVersion"); + + b.ToTable("entity_vault_history"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryDefinition", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("Key") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("key"); + + b.Property("KeyValueStoreEntityId") + .HasColumnType("bigint") + .HasColumnName("key_value_store_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); + + b.HasIndex("KeyValueStoreEntityId", "Key") + .HasDatabaseName("IX_key_value_store_entry_definition_key_value_store_entity_id~1"); + + b.ToTable("key_value_store_entry_definition"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("IsLocked") + .HasColumnType("boolean") + .HasColumnName("is_locked"); + + b.Property("KeyValueStoreEntryDefinitionId") + .HasColumnType("bigint") + .HasColumnName("key_value_store_entry_definition_id"); + + b.Property("Value") + .HasColumnType("bytea") + .HasColumnName("value"); + + b.HasKey("Id"); + + b.HasIndex("KeyValueStoreEntryDefinitionId", "FromStateVersion"); + + b.ToTable("key_value_store_entry_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreSchemaHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("KeySborTypeKind") + .HasColumnType("sbor_type_kind") + .HasColumnName("key_sbor_type_kind"); + + b.Property("KeySchemaDefiningEntityId") + .HasColumnType("bigint") + .HasColumnName("key_schema_defining_entity_id"); + + b.Property("KeySchemaHash") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("key_schema_hash"); + + b.Property("KeyTypeIndex") + .HasColumnType("bigint") + .HasColumnName("key_type_index"); + + b.Property("KeyValueStoreEntityId") + .HasColumnType("bigint") + .HasColumnName("key_value_store_entity_id"); + + b.Property("ValueSborTypeKind") + .HasColumnType("sbor_type_kind") + .HasColumnName("value_sbor_type_kind"); + + b.Property("ValueSchemaDefiningEntityId") + .HasColumnType("bigint") + .HasColumnName("value_schema_defining_entity_id"); + + b.Property("ValueSchemaHash") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("value_schema_hash"); + + b.Property("ValueTypeIndex") + .HasColumnType("bigint") + .HasColumnName("value_type_index"); + + b.HasKey("Id"); + + b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); + + b.ToTable("key_value_store_schema_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction", b => + { + b.Property("StateVersion") + .HasColumnType("bigint") + .HasColumnName("state_version"); + + b.Property("AffectedGlobalEntities") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("affected_global_entities"); + + b.Property("BalanceChanges") + .HasColumnType("jsonb") + .HasColumnName("balance_changes"); + + b.Property("CreatedTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("created_timestamp"); + + b.Property("Epoch") + .HasColumnType("bigint") + .HasColumnName("epoch"); + + b.Property("FeePaid") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("fee_paid"); + + b.Property("IndexInEpoch") + .HasColumnType("bigint") + .HasColumnName("index_in_epoch"); + + b.Property("IndexInRound") + .HasColumnType("bigint") + .HasColumnName("index_in_round"); + + b.Property("NormalizedRoundTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("normalized_round_timestamp"); + + b.Property("ReceiptCostingParameters") + .IsRequired() + .HasColumnType("jsonb") + .HasColumnName("receipt_costing_parameters"); + + b.Property("ReceiptErrorMessage") + .HasColumnType("text") + .HasColumnName("receipt_error_message"); + + b.Property("ReceiptEventEmitters") + .IsRequired() + .HasColumnType("jsonb[]") + .HasColumnName("receipt_event_emitters"); + + b.Property("ReceiptEventNames") + .IsRequired() + .HasColumnType("text[]") + .HasColumnName("receipt_event_names"); + + b.Property("ReceiptEventSborTypeKinds") + .IsRequired() + .HasColumnType("sbor_type_kind[]") + .HasColumnName("receipt_event_sbor_type_kinds"); + + b.Property("ReceiptEventSbors") + .IsRequired() + .HasColumnType("bytea[]") + .HasColumnName("receipt_event_sbors"); + + b.Property("ReceiptEventSchemaEntityIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("receipt_event_schema_entity_ids"); + + b.Property("ReceiptEventSchemaHashes") + .IsRequired() + .HasColumnType("bytea[]") + .HasColumnName("receipt_event_schema_hashes"); + + b.Property("ReceiptEventTypeIndexes") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("receipt_event_type_indexes"); + + b.Property("ReceiptFeeDestination") + .HasColumnType("jsonb") + .HasColumnName("receipt_fee_destination"); + + b.Property("ReceiptFeeSource") + .HasColumnType("jsonb") + .HasColumnName("receipt_fee_source"); + + b.Property("ReceiptFeeSummary") + .IsRequired() + .HasColumnType("jsonb") + .HasColumnName("receipt_fee_summary"); + + b.Property("ReceiptNextEpoch") + .HasColumnType("jsonb") + .HasColumnName("receipt_next_epoch"); + + b.Property("ReceiptOutput") + .HasColumnType("jsonb") + .HasColumnName("receipt_output"); + + b.Property("ReceiptStateUpdates") + .IsRequired() + .HasColumnType("jsonb") + .HasColumnName("receipt_state_updates"); + + b.Property("ReceiptStatus") + .HasColumnType("ledger_transaction_status") + .HasColumnName("receipt_status"); + + b.Property("ReceiptTreeHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("receipt_tree_hash"); + + b.Property("RoundInEpoch") + .HasColumnType("bigint") + .HasColumnName("round_in_epoch"); + + b.Property("RoundTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("round_timestamp"); + + b.Property("StateTreeHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("state_tree_hash"); + + b.Property("TipPaid") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("tip_paid"); + + b.Property("TransactionTreeHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("transaction_tree_hash"); + + b.Property("discriminator") + .HasColumnType("ledger_transaction_type"); + + b.HasKey("StateVersion"); + + b.HasIndex("RoundTimestamp"); + + b.HasIndex("Epoch", "RoundInEpoch") + .IsUnique() + .HasFilter("index_in_round = 0"); + + b.ToTable("ledger_transactions"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("StateVersion") + .HasColumnType("bigint") + .HasColumnName("state_version"); + + b.Property("discriminator") + .HasColumnType("ledger_transaction_marker_type"); + + b.HasKey("Id"); + + b.HasIndex("StateVersion"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdDataHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("Data") + .HasColumnType("bytea") + .HasColumnName("data"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("IsLocked") + .HasColumnType("boolean") + .HasColumnName("is_locked"); + + b.Property("NonFungibleIdDefinitionId") + .HasColumnType("bigint") + .HasColumnName("non_fungible_id_definition_id"); + + b.HasKey("Id"); + + b.HasIndex("NonFungibleIdDefinitionId", "FromStateVersion"); + + b.ToTable("non_fungible_id_data_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdDefinition", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("NonFungibleId") + .IsRequired() + .HasColumnType("text") + .HasColumnName("non_fungible_id"); + + b.Property("NonFungibleResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("non_fungible_resource_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); + + b.HasIndex("NonFungibleResourceEntityId", "NonFungibleId", "FromStateVersion") + .IsUnique() + .HasDatabaseName("IX_non_fungible_id_definition_non_fungible_resource_entity_id~1"); + + b.ToTable("non_fungible_id_definition"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdLocationHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("NonFungibleIdDataId") + .HasColumnType("bigint") + .HasColumnName("non_fungible_id_definition_id"); + + b.Property("VaultEntityId") + .HasColumnType("bigint") + .HasColumnName("vault_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); + + b.ToTable("non_fungible_id_location_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleSchemaHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.Property("SborTypeKind") + .HasColumnType("sbor_type_kind") + .HasColumnName("sbor_type_kind"); + + b.Property("SchemaDefiningEntityId") + .HasColumnType("bigint") + .HasColumnName("schema_defining_entity_id"); + + b.Property("SchemaHash") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("schema_hash"); + + b.Property("TypeIndex") + .HasColumnType("bigint") + .HasColumnName("type_index"); + + b.HasKey("Id"); + + b.HasIndex("ResourceEntityId", "FromStateVersion"); + + b.ToTable("non_fungible_schema_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageBlueprintAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property>("PackageBlueprintIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("package_blueprint_ids"); + + b.Property("PackageEntityId") + .HasColumnType("bigint") + .HasColumnName("package_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("PackageEntityId", "FromStateVersion"); + + b.ToTable("package_blueprint_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageBlueprintHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("AuthTemplate") + .HasColumnType("jsonb") + .HasColumnName("auth_template"); + + b.Property("AuthTemplateIsLocked") + .HasColumnType("boolean") + .HasColumnName("auth_template_is_locked"); + + b.Property("Definition") + .IsRequired() + .HasColumnType("jsonb") + .HasColumnName("definition"); + + b.Property>("DependantEntityIds") + .HasColumnType("bigint[]") + .HasColumnName("dependant_entity_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("Name") + .IsRequired() + .HasColumnType("text") + .HasColumnName("name"); + + b.Property("PackageEntityId") + .HasColumnType("bigint") + .HasColumnName("package_entity_id"); + + b.Property("RoyaltyConfig") + .HasColumnType("jsonb") + .HasColumnName("royalty_config"); + + b.Property("RoyaltyConfigIsLocked") + .HasColumnType("boolean") + .HasColumnName("royalty_config_is_locked"); + + b.Property("Version") + .IsRequired() + .HasColumnType("text") + .HasColumnName("version"); + + b.HasKey("Id"); + + b.HasIndex("PackageEntityId", "FromStateVersion"); + + b.HasIndex("PackageEntityId", "Name", "Version", "FromStateVersion"); + + b.ToTable("package_blueprint_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageCodeAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property>("PackageCodeIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("package_code_ids"); + + b.Property("PackageEntityId") + .HasColumnType("bigint") + .HasColumnName("package_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("PackageEntityId", "FromStateVersion"); + + b.ToTable("package_code_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageCodeHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("Code") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("code"); + + b.Property("CodeHash") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("code_hash"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("PackageEntityId") + .HasColumnType("bigint") + .HasColumnName("package_entity_id"); + + b.Property("VmType") + .HasColumnType("package_vm_type") + .HasColumnName("vm_type"); + + b.HasKey("Id"); + + b.HasIndex("PackageEntityId", "FromStateVersion"); + + b.ToTable("package_code_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EndEpochExclusive") + .HasColumnType("bigint") + .HasColumnName("end_epoch_exclusive"); + + b.Property("IntentHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("intent_hash"); + + b.Property("PayloadHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("payload_hash"); + + b.Property("PayloadId") + .HasColumnType("bigint") + .HasColumnName("payload_id"); + + b.Property("VersionControl") + .IsConcurrencyToken() + .ValueGeneratedOnAddOrUpdate() + .HasColumnType("xid") + .HasColumnName("xmin"); + + b.HasKey("Id"); + + b.HasIndex("IntentHash"); + + b.HasIndex("PayloadHash") + .IsUnique(); + + b.ToTable("pending_transactions"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("NotarizedTransactionBlob") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("notarized_transaction_blob"); + + b.Property("PendingTransactionId") + .HasColumnType("bigint") + .HasColumnName("pending_transaction_id"); + + b.HasKey("Id"); + + b.HasIndex("PendingTransactionId") + .IsUnique(); + + b.ToTable("pending_transaction_payloads"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ResourceEntitySupplyHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.Property("TotalBurned") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("total_burned"); + + b.Property("TotalMinted") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("total_minted"); + + b.Property("TotalSupply") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("total_supply"); + + b.HasKey("Id"); + + b.HasIndex("ResourceEntityId", "FromStateVersion"); + + b.ToTable("resource_entity_supply_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ResourceHolder", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("Balance") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("balance"); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("LastUpdatedAtStateVersion") + .HasColumnType("bigint") + .HasColumnName("last_updated_at_state_version"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "ResourceEntityId") + .IsUnique(); + + b.HasIndex("EntityId", "ResourceEntityId", "Balance"); + + b.ToTable("resource_holders"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SchemaEntryAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("schema_entry_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SchemaEntryDefinition", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("Schema") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("schema"); + + b.Property("SchemaHash") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("schema_hash"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "SchemaHash"); + + b.ToTable("schema_entry_definition"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("discriminator") + .HasColumnType("state_type"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("state_history"); + + b.HasDiscriminator("discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("unverified_standard_metadata_aggregate_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("Discriminator") + .HasColumnType("standard_metadata_key") + .HasColumnName("discriminator"); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("IsDeleted") + .HasColumnType("boolean") + .HasColumnName("is_deleted"); + + b.Property("IsLocked") + .HasColumnType("boolean") + .HasColumnName("is_locked"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "Discriminator", "FromStateVersion"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator("Discriminator"); + + b.UseTphMappingStrategy(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("Epoch") + .HasColumnType("bigint") + .HasColumnName("epoch"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("Stake") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("stake"); + + b.Property("ValidatorPublicKeyHistoryId") + .HasColumnType("bigint") + .HasColumnName("validator_public_key_history_id"); + + b.HasKey("Id"); + + b.HasIndex("Epoch"); + + b.HasIndex("FromStateVersion"); + + b.HasIndex("ValidatorPublicKeyHistoryId"); + + b.ToTable("validator_active_set_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorCumulativeEmissionHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EpochNumber") + .HasColumnType("bigint") + .HasColumnName("epoch_number"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("ParticipationInActiveSet") + .HasColumnType("bigint") + .HasColumnName("participation_in_active_set"); + + b.Property("ProposalsMade") + .HasColumnType("bigint") + .HasColumnName("proposals_made"); + + b.Property("ProposalsMissed") + .HasColumnType("bigint") + .HasColumnName("proposals_missed"); + + b.Property("ValidatorEntityId") + .HasColumnType("bigint") + .HasColumnName("validator_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("ValidatorEntityId", "EpochNumber"); + + b.HasIndex("ValidatorEntityId", "FromStateVersion"); + + b.ToTable("validator_cumulative_emission_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("Key") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("key"); + + b.Property("KeyType") + .HasColumnType("public_key_type") + .HasColumnName("key_type"); + + b.Property("ValidatorEntityId") + .HasColumnType("bigint") + .HasColumnName("validator_entity_id"); + + b.HasKey("Id"); + + b.HasIndex("ValidatorEntityId", "FromStateVersion"); + + b.HasIndex("ValidatorEntityId", "KeyType", "Key"); + + b.ToTable("validator_public_key_history"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountAuthorizedNonFungibleBadgeDepositorEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountAuthorizedDepositorEntryHistory"); + + b.Property("NonFungibleId") + .IsRequired() + .HasColumnType("text") + .HasColumnName("non_fungible_id"); + + b.Property("ResourceEntityId") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.HasIndex("AccountEntityId", "ResourceEntityId", "NonFungibleId", "FromStateVersion") + .HasDatabaseName("IX_account_authorized_depositor_entry_history_account_entity_~1") + .HasFilter("discriminator = 'non_fungible'"); + + b.ToTable("account_authorized_depositor_entry_history"); + + b.HasDiscriminator().HasValue(AuthorizedDepositorBadgeType.NonFungible); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountAuthorizedResourceBadgeDepositorEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountAuthorizedDepositorEntryHistory"); + + b.Property("ResourceEntityId") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.HasIndex("AccountEntityId", "ResourceEntityId", "FromStateVersion") + .HasDatabaseName("IX_account_authorized_depositor_entry_history_account_entity_~2") + .HasFilter("discriminator = 'resource'"); + + b.ToTable("account_authorized_depositor_entry_history"); + + b.HasDiscriminator().HasValue(AuthorizedDepositorBadgeType.Resource); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccessControllerEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalAccessController); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccountEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalAccountComponent); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccountLockerEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalAccountLocker); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalConsensusManager", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalConsensusManager); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalFungibleResourceEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.Property("Divisibility") + .HasColumnType("integer") + .HasColumnName("divisibility"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalFungibleResource); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalGenericComponentEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalGenericComponent); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalIdentityEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalIdentity); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalMultiResourcePoolEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalMultiResourcePool); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalNonFungibleResourceEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.Property>("NonFungibleDataMutableFields") + .IsRequired() + .HasColumnType("text[]") + .HasColumnName("non_fungible_data_mutable_fields"); + + b.Property("NonFungibleIdType") + .HasColumnType("non_fungible_id_type") + .HasColumnName("non_fungible_id_type"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalNonFungibleResource); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalOneResourcePoolEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalOneResourcePool); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalPackageEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalPackage); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTransactionTrackerEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalTransactionTracker); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTwoResourcePoolEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalTwoResourcePool); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalValidatorEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.GlobalValidator); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalFungibleVaultEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.InternalFungibleVault); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalGenericComponentEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.InternalGenericComponent); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalKeyValueStoreEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.InternalKeyValueStore); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalNonFungibleVaultEntity", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + + b.Property("BlueprintName") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_name"); + + b.Property("BlueprintVersion") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text") + .HasColumnName("blueprint_version"); + + b.ToTable("entities"); + + b.HasDiscriminator().HasValue(EntityType.InternalNonFungibleVault); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleResourceAggregatedVaultsHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); + + b.Property("Balance") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("balance"); + + b.ToTable("entity_resource_aggregated_vaults_history"); + + b.HasDiscriminator().HasValue(ResourceType.Fungible); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleResourceAggregatedVaultsHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); + + b.Property("TotalCount") + .HasColumnType("bigint") + .HasColumnName("total_count"); + + b.ToTable("entity_resource_aggregated_vaults_history"); + + b.HasDiscriminator().HasValue(ResourceType.NonFungible); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleVaultHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); + + b.Property("Balance") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("balance"); + + b.Property("IsRoyaltyVault") + .HasColumnType("boolean") + .HasColumnName("is_royalty_vault"); + + b.ToTable("entity_vault_history"); + + b.HasDiscriminator().HasValue(ResourceType.Fungible); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleVaultHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); + + b.Property>("NonFungibleIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("non_fungible_ids"); + + b.ToTable("entity_vault_history"); + + b.HasDiscriminator().HasValue(ResourceType.NonFungible); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.FlashLedgerTransaction", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); + + b.ToTable("ledger_transactions"); + + b.HasDiscriminator().HasValue(LedgerTransactionType.Flash); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GenesisLedgerTransaction", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); + + b.ToTable("ledger_transactions"); + + b.HasDiscriminator().HasValue(LedgerTransactionType.Genesis); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.RoundUpdateLedgerTransaction", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); + + b.ToTable("ledger_transactions"); + + b.HasDiscriminator().HasValue(LedgerTransactionType.RoundUpdate); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UserLedgerTransaction", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); + + b.Property("IntentHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("intent_hash"); + + b.Property("ManifestClasses") + .IsRequired() + .HasColumnType("ledger_transaction_manifest_class[]") + .HasColumnName("manifest_classes"); + + b.Property("ManifestInstructions") + .IsRequired() + .HasColumnType("text") + .HasColumnName("manifest_instructions"); + + b.Property("Message") + .HasColumnType("jsonb") + .HasColumnName("message"); + + b.Property("PayloadHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("payload_hash"); + + b.Property("RawPayload") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("raw_payload"); + + b.Property("SignedIntentHash") + .IsRequired() + .HasColumnType("text") + .HasColumnName("signed_intent_hash"); + + b.HasIndex("IntentHash") + .HasFilter("intent_hash IS NOT NULL"); + + NpgsqlIndexBuilderExtensions.HasMethod(b.HasIndex("IntentHash"), "hash"); + + b.ToTable("ledger_transactions"); + + b.HasDiscriminator().HasValue(LedgerTransactionType.User); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AffectedGlobalEntityTransactionMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("EntityId") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.HasIndex("EntityId", "StateVersion") + .HasDatabaseName("IX_ledger_transaction_markers_entity_id_state_version1") + .HasFilter("discriminator = 'affected_global_entity'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.AffectedGlobalEntity); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EventGlobalEmitterTransactionMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("EntityId") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.HasIndex("EntityId", "StateVersion") + .HasFilter("discriminator = 'event_global_emitter'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.EventGlobalEmitter); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EventLedgerTransactionMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("EntityId") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("EventType") + .HasColumnType("ledger_transaction_marker_event_type") + .HasColumnName("event_type"); + + b.Property("Quantity") + .HasPrecision(1000) + .HasColumnType("numeric") + .HasColumnName("quantity"); + + b.Property("ResourceEntityId") + .HasColumnType("bigint") + .HasColumnName("resource_entity_id"); + + b.HasIndex("EventType", "EntityId", "StateVersion") + .HasFilter("discriminator = 'event'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Event); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestAddressLedgerTransactionMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("EntityId") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property("OperationType") + .HasColumnType("ledger_transaction_marker_operation_type") + .HasColumnName("operation_type"); + + b.HasIndex("OperationType", "EntityId", "StateVersion") + .HasFilter("discriminator = 'manifest_address'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestClassMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("IsMostSpecific") + .HasColumnType("boolean") + .HasColumnName("is_most_specific"); + + b.Property("ManifestClass") + .HasColumnType("ledger_transaction_manifest_class") + .HasColumnName("manifest_class"); + + b.HasIndex(new[] { "ManifestClass", "StateVersion" }, "IX_ledger_transaction_markers_manifest_class") + .HasFilter("discriminator = 'manifest_class'"); + + b.HasIndex(new[] { "ManifestClass", "StateVersion" }, "IX_ledger_transaction_markers_manifest_class_is_most_specific") + .HasFilter("discriminator = 'manifest_class' and is_most_specific = true"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestClass); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("OriginType") + .HasColumnType("ledger_transaction_marker_origin_type") + .HasColumnName("origin_type"); + + b.HasIndex("OriginType", "StateVersion") + .HasFilter("discriminator = 'origin'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Origin); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.JsonStateHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); + + b.Property("JsonState") + .IsRequired() + .HasColumnType("jsonb") + .HasColumnName("json_state"); + + b.ToTable("state_history"); + + b.HasDiscriminator().HasValue(StateType.Json); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SborStateHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); + + b.Property("SborState") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("sbor_state"); + + b.Property("SborTypeKind") + .HasColumnType("sbor_type_kind") + .HasColumnName("sbor_type_kind"); + + b.Property("SchemaDefiningEntityId") + .HasColumnType("bigint") + .HasColumnName("schema_defining_entity_id"); + + b.Property("SchemaHash") + .IsRequired() + .HasColumnType("bytea") + .HasColumnName("schema_hash"); + + b.Property("TypeIndex") + .HasColumnType("bigint") + .HasColumnName("type_index"); + + b.ToTable("state_history"); + + b.HasDiscriminator().HasValue(StateType.Sbor); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.DappAccountLockerUnverifiedStandardMetadataEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory"); + + b.Property("EntityIds") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint[]") + .HasColumnName("entity_ids"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator().HasValue(StandardMetadataKey.DappAccountLocker); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.DappAccountTypeUnverifiedStandardMetadataEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory"); + + b.Property("Values") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text[]") + .HasColumnName("values"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator().HasValue(StandardMetadataKey.DappAccountType); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.DappClaimedEntitiesUnverifiedStandardMetadataEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory"); + + b.Property("EntityIds") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint[]") + .HasColumnName("entity_ids"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator().HasValue(StandardMetadataKey.DappClaimedEntities); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.DappClaimedWebsitesUnverifiedStandardMetadataEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory"); + + b.Property("Values") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("text[]") + .HasColumnName("values"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator().HasValue(StandardMetadataKey.DappClaimedWebsites); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.DappDefinitionUnverifiedStandardMetadataEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory"); + + b.Property("EntityIds") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint[]") + .HasColumnName("entity_ids"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator().HasValue(StandardMetadataKey.DappDefinition); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.DappDefinitionsUnverifiedStandardMetadataEntryHistory", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.UnverifiedStandardMetadataEntryHistory"); + + b.Property("EntityIds") + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("bigint[]") + .HasColumnName("entity_ids"); + + b.ToTable("unverified_standard_metadata_entry_history"); + + b.HasDiscriminator().HasValue(StandardMetadataKey.DappDefinitions); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => + { + b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionGatewayHandling", "GatewayHandling", b1 => + { + b1.Property("PendingTransactionId") + .HasColumnType("bigint"); + + b1.Property("AttemptedSubmissionToNodesCount") + .HasColumnType("integer") + .HasColumnName("node_submission_count"); + + b1.Property("FirstSubmittedToGatewayTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("first_submitted_to_gateway_timestamp"); + + b1.Property("HandlingStatusReason") + .HasColumnType("text") + .HasColumnName("handling_status_reason"); + + b1.Property("ResubmitFromTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("resubmit_from_timestamp"); + + b1.HasKey("PendingTransactionId"); + + b1.HasIndex("FirstSubmittedToGatewayTimestamp"); + + b1.HasIndex("ResubmitFromTimestamp"); + + b1.ToTable("pending_transactions"); + + b1.WithOwner() + .HasForeignKey("PendingTransactionId"); + }); + + b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionLedgerDetails", "LedgerDetails", b1 => + { + b1.Property("PendingTransactionId") + .HasColumnType("bigint"); + + b1.Property("CommitTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("commit_timestamp"); + + b1.Property("InitialRejectionReason") + .HasColumnType("text") + .HasColumnName("initial_rejection_reason"); + + b1.Property("IntentLedgerStatus") + .HasColumnType("pending_transaction_intent_ledger_status") + .HasColumnName("intent_status"); + + b1.Property("LatestRejectionReason") + .HasColumnType("text") + .HasColumnName("latest_rejection_reason"); + + b1.Property("LatestRejectionTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("latest_rejection_timestamp"); + + b1.Property("PayloadLedgerStatus") + .HasColumnType("pending_transaction_payload_ledger_status") + .HasColumnName("payload_status"); + + b1.HasKey("PendingTransactionId"); + + b1.ToTable("pending_transactions"); + + b1.WithOwner() + .HasForeignKey("PendingTransactionId"); + }); + + b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionNetworkDetails", "NetworkDetails", b1 => + { + b1.Property("PendingTransactionId") + .HasColumnType("bigint"); + + b1.Property("LastSubmitErrorTitle") + .HasColumnType("text") + .HasColumnName("last_submit_error"); + + b1.Property("LatestNodeSubmissionTimestamp") + .HasColumnType("timestamp with time zone") + .HasColumnName("latest_node_submission_timestamp"); + + b1.Property("LatestNodeSubmissionWasAccepted") + .HasColumnType("boolean") + .HasColumnName("latest_node_submission_was_accepted"); + + b1.Property("LatestSubmittedToNodeName") + .HasColumnType("text") + .HasColumnName("latest_submitted_to_node_name"); + + b1.HasKey("PendingTransactionId"); + + b1.ToTable("pending_transactions"); + + b1.WithOwner() + .HasForeignKey("PendingTransactionId"); + }); + + b.Navigation("GatewayHandling") + .IsRequired(); + + b.Navigation("LedgerDetails") + .IsRequired(); + + b.Navigation("NetworkDetails") + .IsRequired(); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => + { + b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", "PendingTransaction") + .WithOne("Payload") + .HasForeignKey("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", "PendingTransactionId") + .OnDelete(DeleteBehavior.Cascade); + + b.Navigation("PendingTransaction"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => + { + b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", "PublicKey") + .WithMany() + .HasForeignKey("ValidatorPublicKeyHistoryId") + .OnDelete(DeleteBehavior.Cascade) + .IsRequired(); + + b.Navigation("PublicKey"); + }); + + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => + { + b.Navigation("Payload"); + }); +#pragma warning restore 612, 618 + } + } +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240926150449_RemoveUniqueConstrainFromAccountLockerIndex.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240926150449_RemoveUniqueConstrainFromAccountLockerIndex.cs new file mode 100644 index 000000000..8e5d2f9b3 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240926150449_RemoveUniqueConstrainFromAccountLockerIndex.cs @@ -0,0 +1,101 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using Microsoft.EntityFrameworkCore.Migrations; + +#nullable disable + +namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations +{ + /// + public partial class RemoveUniqueConstrainFromAccountLockerIndex : Migration + { + /// + protected override void Up(MigrationBuilder migrationBuilder) + { + migrationBuilder.DropIndex( + name: "IX_account_locker_entry_resource_vault_definition_account_lock~", + table: "account_locker_entry_resource_vault_definition"); + + migrationBuilder.CreateIndex( + name: "IX_account_locker_entry_resource_vault_definition_account_lock~", + table: "account_locker_entry_resource_vault_definition", + columns: new[] { "account_locker_definition_id", "from_state_version" }); + } + + /// + protected override void Down(MigrationBuilder migrationBuilder) + { + migrationBuilder.DropIndex( + name: "IX_account_locker_entry_resource_vault_definition_account_lock~", + table: "account_locker_entry_resource_vault_definition"); + + migrationBuilder.CreateIndex( + name: "IX_account_locker_entry_resource_vault_definition_account_lock~", + table: "account_locker_entry_resource_vault_definition", + columns: new[] { "account_locker_definition_id", "from_state_version" }, + unique: true); + } + } +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql index fba409baa..43818ddaa 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql @@ -1301,3 +1301,29 @@ BEGIN END $EF$; COMMIT; +START TRANSACTION; + + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240926150449_RemoveUniqueConstrainFromAccountLockerIndex') THEN + DROP INDEX "IX_account_locker_entry_resource_vault_definition_account_lock~"; + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240926150449_RemoveUniqueConstrainFromAccountLockerIndex') THEN + CREATE INDEX "IX_account_locker_entry_resource_vault_definition_account_lock~" ON account_locker_entry_resource_vault_definition (account_locker_definition_id, from_state_version); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240926150449_RemoveUniqueConstrainFromAccountLockerIndex') THEN + INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") + VALUES ('20240926150449_RemoveUniqueConstrainFromAccountLockerIndex', '8.0.2'); + END IF; +END $EF$; +COMMIT; + diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs index 80aa769b0..fbb2e79ec 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs @@ -62,7 +62,7 @@ * permissions under this License. */ -// +// using System; using System.Collections.Generic; using System.Numerics; @@ -265,8 +265,7 @@ protected override void BuildModel(ModelBuilder modelBuilder) b.HasKey("Id"); - b.HasIndex("AccountLockerDefinitionId", "FromStateVersion") - .IsUnique(); + b.HasIndex("AccountLockerDefinitionId", "FromStateVersion"); b.ToTable("account_locker_entry_resource_vault_definition"); });