Your SDK ships to thousands of apps. See what happens next.

SDK Garden is usage analytics for the libraries you publish. Add a small client to your SDK and find out which versions are still installed, where setup fails, and which methods developers actually call — across every language you support.

MIT licensed. Free for one SDK, or self-host it for free.

Init rate
96.4%
Sessions · 7d
48,210
p50 init
41ms
3.2.00.8% err
3.1.41.1% err
2.9.112.6% err
2.4.02.0% err
2.9.1 is still on 15% of installs and fails twelve times as often. Worth a deprecation notice.

// what you'll know

Answers to the questions your issue tracker can't

Download counts tell you who installed your SDK. They don't tell you what happened after. These are the questions developer-experience teams ask us most.

Which versions are still out there?

See the share of real sessions on each release, not just download numbers. Know when it's safe to drop support for an old major — SDK Garden flags versions nobody has run for 30 days.

3.x · 81% 2.9
3.x2.9.xolder
share of sessions, last 30 days

Where does setup go wrong?

Follow every session from process start to the first successful call. A drop between "started" and "initialized" usually means a missing key, a bad config, or a runtime you don't support yet.

started100%
initialized83%
called a method61%
used a feature34%
17% of sessions never finish initializing — see which versions and runtimes

Which methods does anyone actually call?

Wrap your public methods and get call counts, error rates and durations for each. Find the API surface people depend on before you change it — and the parts nobody uses.

methodcallserrorsp50
charges.create1.2M0.4%88ms
customers.get640K0.1%31ms
refunds.create52K2.3%120ms
legacy.sync14——
legacy.sync: 14 calls in 90 days

Did the last release make things worse?

Error rates per version, compared with your average, the day a release starts rolling out. Catch the regression while it's on 3% of installs, not 60%.

3.2.00.8%
3.1.41.1%
3.3.0-rc4.7%
3.3.0-rc errors at 4× the account average

// integration

About fifteen lines, once

You add the client to your SDK. Your users don't install or configure anything.

  1. Create an SDK and a keyOne per client library you publish.
  2. Initialize the client when your SDK loadsEvents are batched and sent in the background.
  3. Wrap the public methods you care aboutCalls, durations and errors are recorded for each.

Network failures are swallowed — the client never throws into your users' code. Set disabled: true to turn it off, for example when your own users opt out.

// npm install sdk-garden-js
import SdkGarden from 'sdk-garden-js';
import { version } from '../package.json';

SdkGarden.init({
  apiKey: 'sgk_…',
  sdkName: 'acme-node',
  sdkVersion: version,
});

export class Charges {
  @SdkGarden.trackMethod('charges.create')
  async create(params: ChargeParams) {
    // your implementation
  }
}

// pricing

Priced per SDK, not per seat

Each client library you ship is its own product, so that's what you pay for. Invite your whole team, and get single sign-on on every paid plan.

Free

$0

For a maintainer with one SDK.

  • 1 SDK
  • 500K events a month
  • 30 days of history
  • Unlimited teammates
Start free

Team

$29 per SDK / month

For companies shipping SDKs in several languages.

  • 5M events a month per SDK
  • 13 months of history
  • Unlimited teammates
  • Single sign-on (OIDC)
  • Email support
Start with Team

Enterprise

Let's talk

For large install bases and procurement requirements.

  • Volume pricing across SDKs
  • Custom event limits and retention
  • Data residency options
  • SLA and invoicing
Email us
$87a month for 3 SDKs on Team

Node, Python, Go, Java and Swift clients would be five SDKs. Each gets its own dashboard, keys and event allowance.

// open source

Run it yourself if you'd rather

The server, dashboard and clients are MIT licensed. Self-hosting is a first-class path, not a trial: the same single Go binary we run, with Postgres and Redis.

No limits on SDKs or events. You keep the data on your infrastructure.

Self-hosting guide →

# needs only Docker
git clone https://github.com/tjb/SDKGarden.git
cd SDKGarden
cp .env.example .env   # set secrets, DEBUG=false
docker build -t sdkgarden:latest .
docker compose -f docker-compose.prod.yml up -d
# → http://localhost:3000

// your users' data

What the client sends, exactly

You're putting this inside other people's apps, so here is the whole list. The client is open source; read it before you ship it.

Sent with events

  • Your SDK's name and version
  • Event type, method name and duration
  • Error type and message, with email addresses redacted
  • A random session ID created each time your SDK initializes
  • Runtime and language version, and how long your SDK took to initialize; in browsers also screen and viewport size, locale, timezone and the site’s origin (never the page path, query string or referrer)

Never sent

  • Argument values or return values of your methods (Python sends only the number of arguments)
  • Cookies, or IDs that follow a person across sessions
  • Anything at all when you pass disabled: true

// questions

Things people ask first

Will it slow down my SDK?

Events go into an in-memory buffer and are sent in batches in the background — on a daemon thread in Python, with fetch in JavaScript. Your methods don't wait on the network.

What happens if SDK Garden is down?

Nothing your users would notice. Network errors are caught inside the client and never reach their code.

How is this different from Sentry or product analytics?

Error trackers show you crashes in apps you own. Product analytics tracks end users. SDK Garden looks at your library across everyone else's apps: versions in the wild, setup success, and which parts of your API get used.

Which languages are supported?

JavaScript/TypeScript (Node and browsers) and Python today. The ingest API is a documented JSON endpoint, so other languages can send events directly while their clients are in progress.

Can we use our identity provider?

Yes. Single sign-on over OpenID Connect works with Okta, Microsoft Entra ID, Google Workspace, Auth0 and others, on every paid plan and when self-hosting.

Find out what your SDK is doing out there.

Free for your first SDK. Setup takes about fifteen minutes, and the dashboard tells you the moment the first event arrives.