/**
 * Radix Gateway API - Babylon
 * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission.  It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up.  The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network.  This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own.  ## Migration guide  Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases).  ## Integration and forward compatibility guarantees  All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects.  When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out.  On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway.  The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare.
 *
 * The version of the OpenAPI document: v1.10.1
 *
 *
 * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
 * https://openapi-generator.tech
 * Do not edit the class manually.
 */
import * as runtime from '../runtime';
import type { EntitiesByRoleRequirementLookupRequest, EntitiesByRoleRequirementLookupResponse, EntitiesByRoleRequirementPageRequest, EntitiesByRoleRequirementPageResponse, ImplicitRequirementsLookupRequest, ImplicitRequirementsLookupResponse, ResourceHoldersRequest, ResourceHoldersResponse } from '../models';
export interface EntitiesByRoleRequirementLookupOperationRequest {
    entitiesByRoleRequirementLookupRequest: EntitiesByRoleRequirementLookupRequest;
}
export interface EntitiesByRoleRequirementPageOperationRequest {
    entitiesByRoleRequirementPageRequest: EntitiesByRoleRequirementPageRequest;
}
export interface ImplicitRequirementsLookupOperationRequest {
    implicitRequirementsLookupRequest: ImplicitRequirementsLookupRequest;
}
export interface ResourceHoldersPageRequest {
    resourceHoldersRequest: ResourceHoldersRequest;
}
/**
 *
 */
export declare class ExtensionsApi extends runtime.BaseAPI {
    /**
     * This endpoint is intended to query for entities that have ever used a given requirement (resource or non-fungible global ID) in their access rules (blueprint authentication templates, owner roles, or role assignments). This endpoint allows querying by multiple requirements. A maximum of `50` requirements can be queried. A maximum of 20 entities per requirement will be returned. To retrieve subsequent pages, use the returned cursor and call the `/extensions/entities-by-role-requirement/page` endpoint.  Behaviour: - Entities are returned in ascending order by the state version in which the requirement was first observed on the ledger. - It may include entities that no longer use the requirement as part of an access rule. - If no entities are found, an empty list will be returned.
     * Get entities by role requirement lookup
     */
    entitiesByRoleRequirementLookupRaw(requestParameters: EntitiesByRoleRequirementLookupOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<EntitiesByRoleRequirementLookupResponse>>;
    /**
     * This endpoint is intended to query for entities that have ever used a given requirement (resource or non-fungible global ID) in their access rules (blueprint authentication templates, owner roles, or role assignments). This endpoint allows querying by multiple requirements. A maximum of `50` requirements can be queried. A maximum of 20 entities per requirement will be returned. To retrieve subsequent pages, use the returned cursor and call the `/extensions/entities-by-role-requirement/page` endpoint.  Behaviour: - Entities are returned in ascending order by the state version in which the requirement was first observed on the ledger. - It may include entities that no longer use the requirement as part of an access rule. - If no entities are found, an empty list will be returned.
     * Get entities by role requirement lookup
     */
    entitiesByRoleRequirementLookup(requestParameters: EntitiesByRoleRequirementLookupOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<EntitiesByRoleRequirementLookupResponse>;
    /**
     * Paginated endpoint returns a page of global entities that have ever used the provided requirement (such as a resource or non-fungible global ID) in their access rules (blueprint authentication templates, owner roles, or role assignments). This endpoint allows querying by a single requirement. By default it returns up to 100 entries are returned per response. This limit can be increased to a maximum of 1000 entries per page using the `limit_per_page` parameter. To retrieve subsequent pages, use the returned cursor and call the `/extensions/entities-by-role-requirement/page` endpoint.  To lookup multiple requirements, please call the `/extensions/entities-by-role-requirement/lookup` endpoint.  Behaviour: - Entities are returned in ascending order by the state version in which the requirement was first observed on the ledger. - It may include entities that no longer use the requirement as part of an access rule. - If no entities are found, an empty list will be returned.
     * Get entities by role requirement page
     */
    entitiesByRoleRequirementPageRaw(requestParameters: EntitiesByRoleRequirementPageOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<EntitiesByRoleRequirementPageResponse>>;
    /**
     * Paginated endpoint returns a page of global entities that have ever used the provided requirement (such as a resource or non-fungible global ID) in their access rules (blueprint authentication templates, owner roles, or role assignments). This endpoint allows querying by a single requirement. By default it returns up to 100 entries are returned per response. This limit can be increased to a maximum of 1000 entries per page using the `limit_per_page` parameter. To retrieve subsequent pages, use the returned cursor and call the `/extensions/entities-by-role-requirement/page` endpoint.  To lookup multiple requirements, please call the `/extensions/entities-by-role-requirement/lookup` endpoint.  Behaviour: - Entities are returned in ascending order by the state version in which the requirement was first observed on the ledger. - It may include entities that no longer use the requirement as part of an access rule. - If no entities are found, an empty list will be returned.
     * Get entities by role requirement page
     */
    entitiesByRoleRequirementPage(requestParameters: EntitiesByRoleRequirementPageOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<EntitiesByRoleRequirementPageResponse>;
    /**
     * Access rules can include [implicit requirements](https://docs.radixdlt.com/docs/advanced-accessrules#implicit-requirements) referencing special system-reserved resource addresses, which have specific meanings for the Radix Engine and are not part of the standard authorization zone system. These implicit requirements typically store their details as a hash, which means the subject of the requirement can\'t be easily resolved. This is where this endpoint comes in. It can resolve the subject of the implicit requirements, using a database of reverse hash lookups populated from ledger data.  The following [resource addresses](https://docs.radixdlt.com/docs/well-known-addresses) are supported: - **Secp256k1 Signature Resource** - **Ed25519 Signature Resource** - **Package of Direct Caller Resource** - **Global Caller Resource** - **System Execution Resource**  When querying, you must provide a pair of the following for each requirement to resolve: - `resource_address` (one of the above) - `non_fungible_id`,  of the requirement.  You can query a maximum of `100` implicit requirements at a time.  See the documentation on [implicit-requirements](https://docs.radixdlt.com/docs/advanced-accessrules#implicit-requirements) for more information.
     * Resolve implicit requirement target from global non-fungible id
     */
    implicitRequirementsLookupRaw(requestParameters: ImplicitRequirementsLookupOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ImplicitRequirementsLookupResponse>>;
    /**
     * Access rules can include [implicit requirements](https://docs.radixdlt.com/docs/advanced-accessrules#implicit-requirements) referencing special system-reserved resource addresses, which have specific meanings for the Radix Engine and are not part of the standard authorization zone system. These implicit requirements typically store their details as a hash, which means the subject of the requirement can\'t be easily resolved. This is where this endpoint comes in. It can resolve the subject of the implicit requirements, using a database of reverse hash lookups populated from ledger data.  The following [resource addresses](https://docs.radixdlt.com/docs/well-known-addresses) are supported: - **Secp256k1 Signature Resource** - **Ed25519 Signature Resource** - **Package of Direct Caller Resource** - **Global Caller Resource** - **System Execution Resource**  When querying, you must provide a pair of the following for each requirement to resolve: - `resource_address` (one of the above) - `non_fungible_id`,  of the requirement.  You can query a maximum of `100` implicit requirements at a time.  See the documentation on [implicit-requirements](https://docs.radixdlt.com/docs/advanced-accessrules#implicit-requirements) for more information.
     * Resolve implicit requirement target from global non-fungible id
     */
    implicitRequirementsLookup(requestParameters: ImplicitRequirementsLookupOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ImplicitRequirementsLookupResponse>;
    /**
     * A paginated endpoint to discover which global entities hold the most of a given resource. More specifically, it returns a page of global entities which hold the given resource, ordered descending by the total fungible balance / total count of non-fungibles stored in vaults in the state tree of that entity (excluding unclaimed royalty balances).  This endpoint operates only at the **current state version**, it is not possible to browse historical data. Because of that, it is not possible to offer stable pagination as data constantly changes. Balances might change between pages being read, which might result in gaps or some entries being returned twice.  Under default Gateway configuration, up to 100 entries are returned per response. This can be increased up to 1000 entries per page with the `limit_per_page` parameter.
     * Get Resource Holders Page
     */
    resourceHoldersPageRaw(requestParameters: ResourceHoldersPageRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ResourceHoldersResponse>>;
    /**
     * A paginated endpoint to discover which global entities hold the most of a given resource. More specifically, it returns a page of global entities which hold the given resource, ordered descending by the total fungible balance / total count of non-fungibles stored in vaults in the state tree of that entity (excluding unclaimed royalty balances).  This endpoint operates only at the **current state version**, it is not possible to browse historical data. Because of that, it is not possible to offer stable pagination as data constantly changes. Balances might change between pages being read, which might result in gaps or some entries being returned twice.  Under default Gateway configuration, up to 100 entries are returned per response. This can be increased up to 1000 entries per page with the `limit_per_page` parameter.
     * Get Resource Holders Page
     */
    resourceHoldersPage(requestParameters: ResourceHoldersPageRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ResourceHoldersResponse>;
}