SDK · @manybases/js

@manybases/js — install and configure

The official Manybases client for the browser and the server: one package, no dependencies, ESM only, types included.

bash

npm install @manybases/js

Every release is published by CI with a provenance attestation linking the tarball to the commit it was built from; npm audit signatures verifies it.

Create a client#

import { createClient } from "@manybases/js";

const mb = createClient(
  process.env.NEXT_PUBLIC_MANYBASES_URL!,
  process.env.NEXT_PUBLIC_MANYBASES_PUBLISHABLE_KEY!,
);

createClient(url, key, options?) returns { auth, from(table), storage }. The URL is the project's data API, as the project page publishes it (https://proj-….manybases.com/v1); the origin alone is accepted too, the SDK adds /v1 itself. The key is the project's pk_ in a browser or on a server, or its sk_ on a server only.

options: fetch (your own implementation), storage (where the session is kept — see auth), storageKey.

Environment variables#

The SDK never reads environment variables itself: a bundler inlines process.env.X only where it is written literally in your application code. Pass the values to createClient.

Variable	Where it goes	What it does — and does not do
`NEXT_PUBLIC_MANYBASES_URL`	browser + server	The project's API URL. Not the management API — that one has no route in this SDK
`NEXT_PUBLIC_MANYBASES_PUBLISHABLE_KEY`	browser	The project's `pk_`. Public by design: it identifies the project and grants nothing on its own. It does not let a visitor read private rows — the access preset of each table decides
`MANYBASES_SECRET_KEY`	server only	The project's `sk_`. It ignores the access matrix and reads every row. Never behind a `NEXT_PUBLIC_` prefix

NEXT_PUBLIC_ is Next's prefix (Vite uses VITE_); the suffix is ours. The dashboard's Deploy → Third-party tab prints this block pre-filled for a project.

What `createClient` refuses#

It throws at construction — before any request — in six cases, each with a message that says what to pass instead:

no URL;
a URL that is not https (http is accepted for localhost only);
a URL with an unexpected path — pass the origin, or the value ending in /v1;
an ak_ key: an account key manages projects, keys and SQL, and this SDK has no route to any of that;
an sk_ key in a browser: it would read every row of the project;
a key that is neither pk_ nor sk_.

On the server, one client per request#

A module-level client shares its session between concurrent requests: a setSession for one visitor would travel with another visitor's request. Build the client inside the request handler.

What it talks to#

The data plane of one project: rows, end-user auth and files. It has no route to the management plane — projects, keys, SQL and logs need an account key, which never belongs in an app. Two areas of the API are not in the SDK yet and will be additions, not breaking changes: DELETE /v1/auth/me (a re-authenticated session and a two-step confirmation) and the spaces routes (four of which confirm in two steps).