Skip to main content
Cesto exposes three integration surfaces. They differ in how much of the experience you own and how much you have to build, and they are designed to be picked up in that order — you can start with an iframe today and move to the server SDK when you need it.

Widgets

No code. One <iframe> renders a live basket card on your page. No key, no JavaScript, no build step.

Web SDK

Frontend. A drop-in invest flow on your own site: your CTA opens a themed Cesto dialog, the user signs in, funds, and invests without leaving your page.

Server SDK

Backend. The full API in TypeScript: baskets, positions, managed wallets, and client-signed open / close / rebalance. You build the entire UI.

At a glance

Not sure which one is yours? Choose your integration walks the decision in one page.

Before you start

1

Get a key

Widgets need nothing. The Web SDK needs a publishable key and the origins you will embed from; the Server SDK needs a secret key and a scope. See API keys.
2

Find your basket slug

Every basket has a slug — the last path segment of its URL on app.cesto.co/product/<slug>. All three surfaces take that slug. You can also list them programmatically with products.list.
3

Build

Follow the quickstart for your surface: Widgets usage, Web SDK quickstart, or the Server SDK quickstart.

Mixing surfaces

They compose. A common shape is a widget in a blog post or newsletter to show the basket, a Web SDK button on the landing page so the invest happens in place, and the Server SDK on your backend to read the resulting positions back into your own dashboard. They all key off the same basket slug, and a position opened through any of them is the same position.
The Web SDK’s publishable key and the Server SDK’s secret key are different credentials with different powers. A cesto_pk_… is safe in a client bundle; a cesto_sk_… never is. See API keys.