CLIENT
LIBRARIES.

Being built

An SDK is a promise to keep something working across versions, which is why publishing one before the API surface has settled is a promise you break on your own users. There is no published SDK yet and this page does not show a package name that does not resolve.

GET STARTED →

What to know

What an SDK would actually be for

Types that match the API, authentication handled once, pagination and retries that behave sensibly, and errors that arrive as something you can branch on. None of that is difficult; all of it is a maintenance commitment.

Why not yet

A library published against a surface that is still moving forces a choice between breaking users and freezing the API. Waiting until v1 is genuinely stable costs early adopters some convenience and costs everybody else far less.

What to do in the meantime

The HTTP surface is complete and directly usable. A bearer token and any HTTP client is the whole integration story today, and code written that way keeps working when a library appears.

Status

Not published. No package exists under any registry, and any package claiming to be an official GRAJ SDK today is not one.

Where to go next

THE HTTP SURFACE.

Everything GRAJ does — orders, catalog, settlements, tax positions, verification — is behind an HTTP interface, because a dashboard that is the only way in keeps everybody who builds things out.

Read it

BUILDING ON THE PLATFORM.

GRAJ is meant to be built on: other people can make things on top of it without asking.

Read it

WHAT THE SDK WILL COVER.

The interesting question about an SDK for a commerce platform is not which language it is in — it is which invariants it enforces for you, so that an integration cannot make the mistakes GRAJ works hard to prevent.

Read it