Skip to main content

Why migrate?

Turnkey’s low-level libraries allow developers to get as close to the bare Turnkey metals as possible, allowing you to specify all request parameters. While some may desire this configurability, it does have a slight cost of convenience. Enter our higher-order libraries — @turnkey/{ sdk-browser, sdk-server, sdk-react } abstract away the details that most developers don’t need to configure, enabling you to focus more on business logic and less on configuration.

How to migrate?

In short, this depends on your use case. Here are some example paths: Turnkey in the server If you’re using Turnkey in a backend setting, you’re most likely using a combination of @turnkey/http and @turnkey/api-key-stamper. The transition to using @turnkey/sdk-server is fairly straightforward: just bring your API key details, and you’ll be able to reduce the amount of code you need to include. Turnkey on the client In a browser setting, you’re most likely using @turnkey/http and @turnkey/api-key-stamper and/or @turnkey/iframe-stamper. If you’re using NextJS or React in general, you’ll benefit from using @turnkey/sdk-react. We’ve included some details on making these transitions below:

Examples

Turnkey in the server To illustrate the difference, here’s an example creating a new Ethereum wallet via a combination of @turnkey/http and @turnkey/api-key-stamper:
And here’s how you might do the same with just @turnkey/sdk-server:
As you can see, much less boilerplate and dealing with low-level details such as activity types and nested results. Turnkey on the client Here’s a similar illustration, starting with an initial combination of @turnkey/http and @turnkey/webauthn-stamper
And here’s how you might do the same with just @turnkey/sdk-react:
For examples of the new SDK library paradigm in practice, please refer to our Demo Wallet (code can be found here).