v1->v2 Migration guide
Migrating from API v1 involves the following changes:- Change the wallet service URL of your requests from
https://api.us1.shinami.com/sui/wallet/v1tohttps://api.us1.shinami.com/sui/wallet/v2. Important: key service URL is not changing. It stays as v1:https://api.us1.shinami.com/sui/key/v1. - Do not send the following requests, which are no longer supported:
shinami_walx_setBeneficiary,shinami_walx_unsetBeneficiary,shinami_walx_getBeneficiary. - If you send
shinami_wal_executeGaslessTransactionBlock, adjust to the updated request and response bodies, which is now aligned with Mysten’s gRPC version of executeTransactionBlock.
Overview
Shinami’s Invisible Wallets abstract away Web3 elements like seed phrases, third-party wallet connections, gas fees, and signing popups. They are embedded, backend wallets under the shared custody of your app and Shinami. Both parties must cooperate in order to obtain a valid signature. You’ll find API endpoints and key usage notes below. If you ever need help you can reach out to us.Use Cases
Core use cases include app-managed NFTs or closed-loop tokens. For a breakdown of the wallets we offer and wallet use-cases, see our high-level guide.Shinami Gas Station Integration
All methods below that write to the Sui blockchain have their gas fees sponsored by you via a Gas Station you create (see the Sui Gas Station FAQ page of our Help Center for how guidance on how to set up a fund and add free Testnet Sui to it). This is because Invisible Wallets are designed to easily onboard Web2-native users (who may not want to download a wallet app, manage a seed phrase, and complete KYC checks to buy SUI for gas).Authentication, Rate Limits and Error Handling
Authentication You authenticate via an access key passed in a header (‘X-Api-Key: ACCESS_KEY’) or in the request url, e.g.https://api.us1.shinami.com/sui/wallet/v2/ACCESS_KEY. We recommend using a request header and not putting access keys in your request URLs for reduced visibility (in logs, etc). These steps are done automatically by our TypeScript SDK.
For more information, including how to set up an access key with Wallet Services rights, see our Authentication and API Keys guide.
Rate Limits
When you surpass the QPS limit for a key, we return a JSON-RPC error code -32010. We recommend implementing retries with a backoff to handle any rate limits errors that arise. You can also adjust the rate limits of your keys to better balance your QPS allotment across your keys.
Error Handling
See our Error Reference for guidance on the errors you may receive from our services, including a section on errors specific to the Invisible Wallet API.
WalletId and Secret Pairing
When you create an Invisible Wallet, you must create, store, link, and never change the following two values:walletId: Your internal id for a wallet. When you provide us awalletIdin a method call, it tells us which Invisible Wallet to use. It could be your internaluserIdvalue, or a new arbitrary and unique value you link to theuserId.secret: Your internal secret for a wallet. ThesessionTokenyou generate with it is combined with Shinami data to obtain a signature from the associated wallet. Ideally it would be different for each wallet so that if onesecretis compromised the rest are not.


Tutorial with E2E sample code
Check out our TypeScript tutorial for more code samples and details on the end-to-end flow of creating and using Invisible Wallets to execute sponsored transactions.Methods
shinami_key_createSession
For security purposes, you must generate a session token before you create a wallet, or sign or execute transactions. Session tokens are valid and can be reused for 10 minutes. You may also use an instance ofShinamiWalletSigner to manage session token generation and refreshes for a given wallet. This is shown in the methods below that have a sessionToken parameter in an additional sample code tab.
Request Parameters
| Name | Type | Description |
|---|---|---|
| secret | string | Used to encrypt and decrypt a wallet’s private key. Therefore, it must always be used with the same walletId and cannot be changed in the future (see walletId and secret pairing) |
{{name}} with the actual value for that name.
| Name | Type | Description |
|---|---|---|
| result | string | sessionToken corresponding to the provided secret. Valid and can be reused for 10 minutes. |
shinami_wal_createWallet
Programmatically generates a unique wallet for a user that is Sui network agnostic (has the same address on Devnet, Testnet, and Mainnet). On the free tier you have a limit of wallet creations per month as shown on the “Sui Wallet Services” tab of the billing page in your dashboard (where you can also see how to upgrade if needed). If you hit this limit, you will get a JSON-RPC code-32012 and should not retry. All other wallet operations will still work for the month, like signing with wallets you’ve already created.
Request Parameters
| Name | Type | Description |
|---|---|---|
| walletId | string | A unique ID you maintain for the wallet. Can be based on your internal user IDs. Note: you cannot change this value in the future, so do not use a value that you or your users might change, such as an editable username. |
| sessionToken | string | The token generated by shinami_key_createSession with the unalterable secret you will permanently associate with this walletId (and, ideally, only this walletId). |
{{name}} with the actual value for that name.
| Type | Description |
|---|---|
| String | The Sui address of the Invisible Wallet created for this walletId. Network-agnostic (the address will be the same on Devnet, Testnet, and Mainnet). |
shinami_wal_getWallet
Retrieve a user’s wallet address based your unique walletId value for it. Request Parameters| Name | Type | Description |
|---|---|---|
| walletId | string | Your unique, internal id for the associated Invisible Wallet. |
{{name}} with the actual value for that name.
| Type | Description |
|---|---|
| String | The Sui address of the Invisible Wallet created for this walletId. Network-agnostic (the address will be the same on Devnet, Testnet, and Mainnet). |
shinami_wal_signTransactionBlock
Signs a fully constructed transaction so that it can be executed. This is a low level API - it requires integration with Gas Station API for transaction sponsorship (if needed) and an RPC provider for transaction execution. This method gives you more control over how you submit transactions to Sui compared toshinami_wal_executeGaslessTransactionBlock, which sponsors, signs, and executes an Invisible Wallet transaction in one method call.
Request Parameters
| Name | Type | Description |
|---|---|---|
| walletId | string | Your unique, internal id for the associated Invisible Wallet. |
| sessionToken | string | The token generated by shinami_key_createSession with the same secret you used when creating this wallet. |
| txBytes | SDK: string | Uint8ArraycURL: string | BCS serialized TransactionData, which includes gas data. It lacks only the sender’s signature (which this method generates) before it can be submitted to the chain. If string, assumed to be Base64 encoded. |
{{name}} with the actual value for that name.
| Name | Type | Description |
|---|---|---|
| signature | string | Base64 encoded transaction signature, signed by the wallet key. To be used alongside the txBytes sent to this method and the gas sponsor’s signature (if applicable) when executing the transaction. |
| txDigest | string | Base 58 encoded transaction digest. |
shinami_wal_signPersonalMessage
Signs a personal message using an Invisible Wallet. The signature can be verified with thePersonalMessage intent scope. The request template below titled End-to-end example with ShinamiWalletSigner - Shinami TS SDK shows an end-to-end example of signing and a message and verifying a signature.
Request Parameters
| Name | Type | Description |
|---|---|---|
| walletId | string | Your unique, internal id for the associated Invisible Wallet. |
| sessionToken | string | The token generated by shinami_key_createSession with the same secret you used when creating this wallet. |
| message | string | Message bytes to be signed. See an example in the request template below titled End-to-end example with ShinamiWalletSigner - Shinami TS SDK |
| wrapBcs | boolean | Optional. Set it to true when calling the API directly to match the verification behavior of the Sui TypeScript SDK. When using the Shinami TypeScript SDK it’s set to true by default. |
{{name}} with the actual value for that name.
| Type | Description |
|---|---|
| string | Base64 encoded signature, produced by the private key of the Invisible Wallet associated with the provided walletId. |
shinami_wal_executeGaslessTransactionBlock
Sponsors, signs, and executes a gasless transaction from a wallet. This is a convenient end-to-end method for submitting sponsored transactions to the chain when you also use Shinami Gas Station. It sponsors the transaction using the Gas Station fund tied to the access key used to make the request. To see how to set up an Access Key with rights to all services, see our Authentication and API Keys guide. Important notes- To call this method, you need an access key that is authorized for Wallet Services and Gas Station
- You cannot use the gas object in a sponsored transaction for other purposes: For example, you cannot write
const [coin] = txb.splitCoins(txb.gas,[txb.pure(100)]);because it’s accessingtxb.gas. If you try to sponsor a TransactionKind that uses the gas object you will get a JSON-RPC-32602error back from the Gas Station sponsorship attempt. - Shinami sponsorship fees: We charge a small fee (in SUI) per sponsorship request to cover our costs. For details, visit the Billing tab in your Shinami dashboard.
| Name | Type | Description |
|---|---|---|
| walletId | string | Your unique, internal id for the associated Invisible Wallet. |
| sessionToken | string | The token generated by shinami_key_createSession with the same secret you used when creating this wallet. |
| cURL only: txBytes | Base64String | Base64 encoded TransactionKind (as opposed to TransactionData) bytes. So, it does not include gas information. |
| cURL only: gasBudget | string | number | null | (Optional) The gas budget you wish to use for the transaction, in MIST. The transaction will fail if the gas cost exceeds this value. - If provided, we use the value as the budget of the sponsorship. - If omitted, we estimate the transaction cost for you. We then add a buffer (5% for non-shared objects, 25% for shared objects) and use that total value as the budget of the sponsorship. Example: "10000000" or 10000000. |
| cURL only: gasPrice. | string | number | null | (Optional) Gas price override. Must be equal to or greater than the current reference gas price. If omitted the current reference price is used. Under normal network conditions, the expectation is that this does not need to be set. For times of high network congestion, setting a gasPrice higher than the reference gas price gives your transaction higher priority. For more info, see Sui’s documentation on gas pricing. Example: "1500" or 1500. |
| cURL only: readMask. | [string] | null | (Optional) A list of the fields you want to be returned from the ExecutedTransaction response (example: ["balance_changes","transaction.digest"]). |
| SDK-only: tx | GaslessTransaction | TransactionKind and additional optional data sender, gasBudget, and gasPrice. The result of a call to buildGaslessTransaction. |
- As a part of auto-budgeting, we put your
transactionBytesthrough asimulateTransactionrequest as a free service before we attempt to sponsor it. This call will generate error messages for certain invalid transactions, such as if thetransactionBytesare transferring an object that’s not owned by thesenderaddress you provide. We’ll return these errors back to you, which should be the same as if you had made asimulateTransactionrequest yourself. We do not do this step if you manually budget, so any issues that would be caught bysimulateTransactionwill instead produce an error when you try to execute the transaction. - In the time between sponsorship and execution, shared objects can change in a way that increases their transaction cost. Therefore, we encourage you to execute sponsored transactions quickly, if possible, to ensure that the sponsorship amount is sufficient. This is why we add a larger buffer on auto-budgeted sponsorships when a shared object is involved. While we believe this buffer will work in most cases, we encourage you to monitor the success rate of your auto-budgeted transactions to gauge whether your specific use-case requires manually setting an even larger
gasBudget.
{{name}} with the actual value for that name.
| Type | Description |
|---|---|
ExecutedTransaction in JSON form | Contains information about the executed transaction with optional fields depending on your readMask request value. |