API & Access

SmartQC can be called from your own systems, not just used through the browser. An API token stands in for a login on requests you make from code — a script, an integration, your ERP — and everything below explains how to get one, what it can do, and how to keep it safe.

In one sentence: generate a token from the right place for what you're connecting — your own account or a laboratory's systems — and send it as a Bearer header on every request.

Looking for the endpoints themselves — methods, paths, parameters, example requests and responses? See the API Reference.

Two kinds of token

There are two distinct scopes, and which one you generate depends on who's calling:

A QC API token is personal — anyone in your company can generate one for themselves, the same way you'd log in yourself, just from a script instead of a browser. A Laboratory API token belongs to one of your own laboratories (see Laboratories) — it isn't available on a Platform laboratory, since that one is shared by every company on SmartQC and no single company's systems should be able to act as it.

Generating a token

Both panels work the same way:

1. Generate token — give it a name (e.g. "Zapier integration", "Warehouse LIMS") so you can tell it apart later if you ever need to revoke it.
2. The token is shown once, in full — "Copy this token now — you will not be able to see it again." There's no way to retrieve it afterwards; if it's lost, generate a new one.
3. It appears in the list with its name, when it was created, when it expires, its status (Active, Expired, or Revoked), and when it was last used.

Tokens expire 90 days after they're generated or last extended. Extend moves the expiry another 90 days out without changing the token itself — nothing on the calling system's end needs to change. Revoke disables a token immediately and permanently; anything still using it loses access on its next request. Both ask for confirmation first.

Authenticating a request

Send the token exactly as you'd send it if it were a password, in the standard Authorization header:

Authorization: Bearer <your-token>

There's nothing else to configure — no separate API key, no signing, no extra header. A missing, expired, revoked, or otherwise invalid token is rejected the same way an unauthenticated request would be.

What each token can do

• QC API — the full range of what you can already do signed in, exactly as your role allows: an Owner's token can do everything an Owner can in the app; a Member's token is limited the same way a Member is. There's no separate, cut-down API surface — it's the same platform, called from code instead of a browser.
• Laboratory API — deliberately narrower, and scoped to that one laboratory: fetching requests assigned to it, reading one request's detail, downloading its documents, updating its status, posting a comment, and uploading a document. It can never see or touch a request assigned to a different laboratory, and it can't reach anything outside the request workflow (catalog, settings, manufacturing). This mirrors exactly what the Laboratory Portal offers a laboratory without a SmartQC account of its own — the API is the same access, for a system instead of a person.

Keeping tokens safe

• Treat a token like a password — anyone holding it can act as whatever it's scoped to, until it's revoked or it expires.
• Give each integration its own token and a name that says what it's for, rather than sharing one token across several systems — if you ever need to cut one integration off, revoking a shared token would take every other integration down with it.
• Revoke a token as soon as an integration is retired or a system that held it changes hands.