harnyMemory API
Authentication
Two kinds of bearer key open the Memory API. Each call names the credential in the Authorization header.
Copy page
Authorization: Bearer $HARNY_APP_KEY
X-Harny-User: <user>| Credential | Opens |
|---|---|
App key (fsa_) | Ingest, completion, recall, data points, audiences, users and usage. The key selects one app, so the app id is never sent in a request body. Send X-Harny-User to name the user the call acts as. Your application holds this key. |
User key (fsk_) | The memory routes for the one user the key names. It needs no X-Harny-User header, and it never reads another user's memory. |
A call with no Authorization header, or with a key that is unknown or revoked, returns 401 unauthorized. One answer covers all three, so a refusal never says which keys exist.
Where keys are created
App keys are created in the console, by the setup command your coding agent runs, or by POST /v1/auth/provision, which creates an app and its first key with no key needed. Each of them shows the key value once. Store it in an environment variable and never in code, chat or a commit.
For a fresh app: create the key, keep it in HARNY_APP_KEY, and start with the Quickstart. Your coding agent can do the same with no account by following harny.ai/auth.md.
Call the API from your server. A key in a browser is exposed to its users.
Naming the user
An app key acts as the user named in X-Harny-User. The value is the id your application already uses for that person. A body identity never selects the user: when you send one, it must equal the user the call acts as. Any other value returns 403 identity-mismatch.
Refusals
| Status | Code | When |
|---|---|---|
| 401 | unauthorized | The key is missing, unknown or revoked. |
| 403 | identity-mismatch | A body identity differs from the user the call acts as. |