Identity model

The SDK’s API key identifies your organization, not an individual person — it’s the same key for every upload your integration makes. Each call also needs to say who is uploading, via a QratiIdentity:

interface QratiIdentity {
  uid: string; // your app's own stable identifier for this person
  fname?: string;
  lname?: string;
}

This is the same model qrati-connect-ts’s custom-auth mode already uses — you’re not creating a Qrati account or asking your users to log in to Qrati. The first time a given uid (scoped to your organization) is seen, Qrati creates a lightweight internal user record for it; every later call with the same uid resolves back to that same record. That’s what makes ownership checks work — a contentId created for one uid can only be completed, failed, or aborted by a call using that same uid.

Setting identity once vs. per call

Bind a default identity when you create the client:

const qrati = createQrati(API_KEY, { uid, fname, lname });
await qrati.upload({ eventId, file });

Or supply it per call — useful if one client instance serves multiple users (e.g. a server-side integration):

const qrati = createQrati(API_KEY);
await qrati.upload({ eventId, file, identity: { uid, fname, lname } });

A per-call identity always overrides the client’s default for that one call.

What uid should be

Any stable string your system already uses to identify the person — a database id, an email, a session id. It doesn’t need to mean anything to Qrati beyond “the same string next time is the same person.”