SDKs & client libraries
Thin, typed wrappers over the same /v1 API — same keys, scopes, and idempotency.
SDKs & client libraries
Thin, typed wrappers over the same /v1 API — same keys, scopes, and idempotency. Prefer raw
REST? That's fully supported too.
Note
First-party SDKs are on the way — build on the REST API today.
Languages
| Language | Status |
|---|---|
| JavaScript / TypeScript | Planned |
| Python | Planned |
| PHP | Planned |
| Ruby | Planned |
| Go | Planned |
| .NET | Planned |
No language above is shipped yet — every status reads Planned, honestly. The raw REST API (see the API reference and the booking-flow guide) is the fully-supported path today, and stays fully supported once SDKs ship — they'll be thin wrappers, not a separate contract.
What it will look like
Once published, an SDK call is the same request you'd make with curl, typed:
# illustrative — package name not yet reserved, nothing to install yet
npm install @storebay/sdk// illustrative — the shape once a JS/TS SDK ships
import { StoreBay } from '@storebay/sdk'
const storebay = new StoreBay({ apiKey: 'sb_test_…' })
const { data } = await storebay.sites.list()Same Bearer credential, same { data, meta } envelope, same scopes and Idempotency-Key — an
SDK never becomes a second API to learn.
Note
SDKs are additive to the REST API, not a replacement for it — every SDK method is a thin
wrapper over the same /v1 endpoint you could call directly.
Contribute
Prefer building against raw REST for now — see Authentication to get a key and the booking-flow guide for a worked example. Watch the changelog for SDK releases as they ship.