Authentication

Every request to /api/v1 must carry the organization's API key in the Authorization header.

Key format

A key looks like smg_live_ followed by 43 characters (letters, digits, -, _) — 52 characters total. It's sent as a Bearer token:

Authorization: Bearer smg_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Example request:

curl -s https://smengo.com/api/v1/org \
  -H "Authorization: Bearer smg_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

Getting a key

The organization owner (the "Manage organization" permission) creates a key right in the app: Settings → Integrations → the "API keys" block → "Create key". Scopes are chosen at creation time — a key's scopes can never be broader than the creator's own permissions. Step by step: API keys in the help center.

The key is shown exactly once, at creation time. Smengo stores only its hash, so a shown key can't be retrieved again — if you lose it, issue a new one and revoke the old one.

What a key can do

Keys are read-only, and a key can never carry more access than the user who created it: its scopes are a subset of that user's permissions in the app. What each scope unlocks is documented in the scopes reference.

Revoking a key

You can revoke a key at any time — every request made with it immediately starts getting 401. A revoked key, a malformed one, an unknown one, or a missing header — Smengo deliberately returns the same 401 unauthorized response for all of these, without disclosing which one applied. That keeps the API from letting an outsider probe whether any given key exists — the error details never distinguish "wrong format" from "this was a real key that got revoked."

The key is a server secret

Like any secret, an API key must never be embedded in code that runs in a browser, a mobile app, or anywhere else a user can reach. Keep it in your backend's environment variables. CORS is disabled for /api/v1 on purpose — the API isn't designed to be called from a browser.

What's next

Was this article helpful?