Skip to content
Qrati SDK

Roadmap

import { Card, CardGrid } from ‘@astrojs/starlight/components’;

@qratilabs/qrati-sdk is the headless version of Qrati Connect — the same platform, called directly instead of embedded as a widget. Connect’s widget does more than upload; the SDK is working through that same surface area, headless, one piece at a time. This page is the honest map of what’s callable today versus what’s coming, so nothing below gets tried in a demo that isn’t actually wired up yet.

Live now

Section titled “Live now”
`create` / `complete` / `fail` / `abort`, plus the high-level `upload()` orchestration with progress. See [Uploads](/docs/guides/uploads/).

Planned

Section titled “Planned”

Roughly in build order — not committed dates, no tickets yet. Each maps to a real piece of the Connect widget, backed by qrati-web’s existing /api/connect/* routes (see each widget page’s source for the exact routes that’ll move to /api/sdk/*):

List/search an org's public events and folders — Connect's `PublicEventsPage`. `qrati.events.list()` / `.search()`. List, search, sort, and paginate an event's uploaded content — Connect's `ContentsPage`/`MediaGallery`. `qrati.content.list()` / `.search()`. An end-user's own upload history across events, with delete — Connect's `MyUploadsPage`. `qrati.content.mine()` / `.delete()`. Emoji reactions on content — Connect's `useReaction` hook. `qrati.content.react()`. Approve/reject queue for moderators — Connect's `CuratePage`. `qrati.curate.queue()` / `.decide()`. Score-ranked standings for contest and reaction-style events — Connect's `LeaderboardPage`. `qrati.events.leaderboard()`.

Method names above are working names, not a committed API — they’ll firm up as each ships.

Languages

Section titled “Languages”

@qratilabs/qrati-sdk is TypeScript today. It’s a wrapper over a plain REST API (the same /api/sdk/* routes the SDK calls), so any language can integrate now without waiting for an official SDK — see the API Reference for the exact request/response shapes to replicate.

Official wrappers planned beyond TypeScript, no committed order: Python, Go, PHP, Java. Each would be a thin client over the same routes and the same uid/fname/lname identity model — no server-side changes needed to support a new language, since the platform already speaks plain HTTP/JSON.

Deliberately not on this list

Section titled “Deliberately not on this list”

A few things Connect’s widget does that the SDK won’t take on, because they’re UI-rendering or platform-hosting concerns, not data-API ones — the whole point of “headless” is that your own UI owns them instead:

  • Client-side photo filters/editing (WebGL filter engine, crop/trim) — apply your own before calling upload().
  • In-gallery ads — a widget-hosting concern, not applicable headless.
  • Full account/auth system (login, register, password reset) — the SDK uses the same lightweight uid/fname/lname identity model the widget’s custom-auth mode already does; see Identity model. It doesn’t need or expose real Qrati accounts.