SDK Reference
@ghayma/sdk is the runtime SDK for apps running on Ghayma — the code your app
calls at runtime, not the code that builds your infrastructure. It is one
package with two entry points.
One package, two entry points
@ghayma/sdk | @ghayma/sdk/client | |
|---|---|---|
| Runs in | Your server — Node.js 18+, Deno, Bun, Cloudflare Workers | The browser — React, Vue, plain JavaScript |
| Credential | A project API key (gsk_…) | Your auth app’s slug. No secret |
| Does | Administers your auth app’s end users, reads and writes storage objects, hands you database connection details | Signs your end users in: login, registration, sessions, 2FA, OAuth, profile |
Building a mobile app? ghayma_auth is the same client for Dart
and Flutter — its own package on pub.dev, with the browser entry’s endpoints,
error codes and session handling in Dart idioms.
Server-side in PHP or Laravel? ghayma/sdk covers both the admin
API and end-user auth.
One install covers both:
npm install @ghayma/sdk// Server — this half holds the key, so it never ships to a browser
import { Ghayma } from "@ghayma/sdk";
const ghayma = new Ghayma({ apiKey: process.env.GHAYMA_API_KEY });
const { users } = await ghayma.auth.listUsers("my-app");
// Browser — authenticates with the app slug alone
import { GhaymaAuth } from "@ghayma/sdk/client";
const auth = new GhaymaAuth({ appSlug: "my-app" });
await auth.login({ email, password });Creating, deleting and resizing infrastructure is not in the SDK: buckets,
databases and auth apps live in the console and
the ghayma CLI. A project whose code runs elsewhere — a mobile app,
or a backend you host yourself — needs no site either: answer No site at
ghayma init.
@ghayma/auth is deprecated: since 0.8.0 it only re-exports
@ghayma/sdk/client, from whichever @ghayma/sdk is installed beside it.
Migrate by changing the import to @ghayma/sdk/client.
Neither entry verifies a user’s JWT on your server — you do that locally against the app’s JWKS. See JWT Verification.
Minimum versions for 2FA
Since 2026-09-30 the auth service applies an app’s 2FA policy to Google and GitHub sign-in as well as to the password login (how). These versions surface the pending second factor from their OAuth methods as a typed error:
| Package | Minimum | An older version, when the second factor is pending |
|---|---|---|
@ghayma/sdk | 1.3.0 | handleOAuthFragment returns false. 1.2.0’s exchangeCodeForSession and signInWithIdToken — so also handleOAuthRedirect after a PKCE redirect — read the step as a session without tokens and report a sign-in |
@ghayma/auth | 0.8.0, with @ghayma/sdk 1.3.0 installed | 0.8.0 re-exports the installed @ghayma/sdk (^1.1.0) and behaves like that version. 0.7.0 and older: handleOAuthFragment returns false |
ghayma_auth (Dart) | 0.2.0 | 0.1.0: exchangeCode, signInWithIdToken and handleRedirect read the step as a session with empty tokens and emit signedIn |
ghayma/sdk (PHP) | 0.2.0 | 0.1.0: exchangeCode and signInWithIdToken fail with a PHP ValueError |
Update every client of an app before you set its 2FA policy to Optional or
Enforced — or now, if it already is. No older version receives tokens for a
user the policy applies to, but each one misreads the pending step, so those
users cannot finish a Google or GitHub sign-in. Bumping @ghayma/auth alone
can keep an older @ghayma/sdk from your lockfile: run
npm i @ghayma/sdk@^1.3.0 and check that npm ls @ghayma/sdk shows 1.3.0 or
later — or better, import from @ghayma/sdk/client directly.