# Polkadot-API

> Next-Gen TS API to interact with Polkadot-based chains

## Docs

- [Top-level client](/client): `PolkadotClient` interface shapes the top-level API for `polkadot-api`. Once we get a client using `createClient` function, we'll find the following:
- [Codegen](/codegen): Technically, to connect to a chain, all you need is just the [provider](/providers). But to interact with it, you need to know the list of storage, runtime, and transaction calls and their types.
- [Getting Started](/getting-started): If you want to quickly get a project up and running, check out the following community templates:
- [Ink!](/ink): Polkadot-API adds typescript definitions for ink! contracts, as well as utilities to encode and decode messages, contract storage and events.
- [Offline API](/offline): The rationale behind the offline api is to allow consumers to do certain actions with PAPI without the need of a provider. As expected, this client is more limited than the regular [`PolkadotClient`](/client).
- [Requirements](/requirements): PAPI is designed to work flawlessly with almost any Polkadot-like chain. Even though, we have some requirements that the chain and environment have to fulfill.
- [Static APIs](/static): The `StaticApis` object provides **synchronous** access to runtime-specific operations that would otherwise be asynchronous. It targets a specific runtime version (identified by the block's code hash), making it ideal for scenarios where you need multiple synchronous operations without repeated async calls.
- [TypedApi](/typed): The `TypedApi` allows to interact with the runtime metadata easily and with a great developer experience. It'll allow to make storage calls, create transactions, etc. It uses the descriptors generated by PAPI CLI (see [Codegen](/codegen) section for a deeper explanation) to generate the types used at devel time. `TypedApi` object looks like:
- [UnsafeApi](/unsafe): The `UnsafeApi` enables interaction with the chain easily to the same extend [TypedApi](/typed) does, but it does not requires any descriptors. It is an advanced method and should only be used if you really know what you are doing.
- [Migrate to V2](/v2migration): PAPI v2 brings a few changes that make development easier, with a more consistent interface throughout the API.
- [Typed Codecs](/typed-codecs): In advanced use cases -mainly for library authors or developer tool creators- it’s often necessary to tap into the **codecs** used in different chain interactions. This is exactly what the `getTypedCodecs` API offers: a **strongly-typed interface** that grants access to all relevant codecs as defined in a chain’s metadata.
- [Types](/types): All the types defined in the metadata of a chain are anonymous: They represent the structure of the data, down to the primitive types.
- [Runtime APIs](/typed/apis): Runtime APIs (aka Runtime calls in other frameworks) directly query the wasm runtime to get some information. In PAPI they're under `typedApi.apis`. Let's see its interface:
- [Constants](/typed/constants): Constants are the simplest structure that we find inside the `TypedApi`. Constants are hard-coded key-value pairs that are embedded in the runtime metadata. In PAPI their structure is just a simple function that return its decoded value.
- [Events](/typed/events): Let's, first of all, understand the interface of an `Event` in polkadot-api. This interface will be common for every section after this one. The main idea is to give the developer as much information as possible:
- [Storage queries](/typed/queries): For `query` we have mainly two different situations. There're two kinds of storage entries: entries with and without keys.
- [Transactions](/typed/tx): Preparing, signing, and broadcasting extrinsics is one of the main purposes of `polkadot-api`. There are two ways to create transactions in PAPI, and will see both of them in this page.
- [View Functions](/typed/view): View functions are particular [Runtime APIs](/typed/apis) linked to pallets. Therefore, their API is exactly the same as any runtime API. They are found under `typedApi.view`. See [APIS](/typed/apis) documentation for usage notes.
- [Extension-based signers](/signers/extensions): In order to use an extension-based wallet, you can use the utilities exported at `polkadot-api/pjs-signer`.
- [Polkadot Signer](/signers): Polkadot-API uses a library-agnostic interface to interact with signers.
- [Raw signer](/signers/raw): PAPI provides a helper to build a [`PolkadotSigner`](/signers/polkadot-signer) instance directly from a raw signing function, provided by a cryptographic library, a hardware wallet, etc. It just deals with the chain logic side and leaves to the consumer the cryptographic signature part.
- [Polkadot-API SDKs](/sdks): The Polkadot-API library is designed to be modular and chain-agnostic, meaning it does not include any business-level logic. It reads the chain metadata to understand how to interact with the chain, but it is up to the developer to define its specific use and purpose.
- [Ink! SDK](/sdks/ink-sdk): The Ink! SDK is a library for interacting with smart contracts, which supports both pallet contracts (for ink!v5 or below) and pallet revive (for ink!v6 and above and solidity).
- [Multisig SDK](/sdks/multisig-sdk): Working with multisig calls is a bit complex, since the call to make depends on the status of the other signatories. The Multisig SDK simplifies this, by offering a function that wraps any transaction into a multisig call.
- [Staking SDK](/sdks/staking-sdk): The Staking SDK simplifies common interactions with the Polkadot staking pallet:
- [Statement SDK](/sdks/statement): The [Statement Store](https://github.com/paritytech/polkadot-sdk/tree/49bd017a06989799141af0809c0fbdd48d67b733/substrate/primitives/statement-store) primitive is an off-chain data store for signed messages (known as statements) accessible via RPC.
- [Bounties SDK](/sdks/governance/bounties): The Bounties SDK provides the following features:
- [Referenda SDK](/sdks/governance/referenda): The Referenda SDK provides the following features:
- [Conviction Voting SDK](/sdks/governance/voting): The Conviction Voting pallet took a few compromises that improved the efficiency of the pallet, at the cost of a harder developer experience. The Conviction Voting SDK simplifies working with on-chain votes:
- [Identity SDK](/sdks/accounts/identity): On-chain identity is usually hard to consume because the way that the data is structured and encoded.
- [Linked Accounts SDK](/sdks/accounts/linked-accounts): The linked accounts SDK resolves relationships between an account and the accounts that can act on its behalf through proxies or multisig accounts.
- [Connect to multiple chains](/recipes/connect-to-multiple-chains): A very common use case is to connect to both the relay chain and a parachain simultaneously, for example polkadot and polkadot people to check for address identities. In this example we will use smoldot for a more complete example.
- [Metadata Caching](/recipes/metadata-caching): In some advanced use cases, it can make sense to cache metadata to speed up the initial loading time of your DApp. However, this should be approached with care, as there are important implications to consider.
- [Make a simple transfer on Westend using Smoldot](/recipes/simple-transfer): For this example we will use bun. Lets initialize the project:
- [Preparing for a runtime upgrade](/recipes/upgrade): With Polkadot-API's support for multiple chains, you can make your dApp prepare for an upcoming runtime upgrade on a chain as long as you can get the metadata for that upgrade.
- [Enhancers](/providers/enhancers): The JSON-RPC interface is completely unopinionated, which makes it simple to create and use middlewares that deal with the JSON-RPC connection.
- [JSON-RPC Providers](/providers): The Polkadot-API entry point is `createClient(provider)`. It takes a `JsonRpcProvider` that connects to a JSON-RPC endpoint, enabling Polkadot-API to interact with the chain.