new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Better Auth · Plugins · all subjects

api-key/schema

3 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

API key object structure with configId and referenceId

API keys include the following structure: id (string), configId (string identifying which configuration the key belongs to), referenceId (string for the owner ID, either userId or organizationId based on the config's references setting), and other fields. The owner type is determined by looking up the configuration.

API Key schema table structure

The apikey table has the following fields: id (string, primary key, unique), configId (string, default 'default'), name (string, optional), start (string, optional, starting characters for UI identification), prefix (string, optional, stored as plain text), key (string, hashed API key), referenceId (string, indexed, owner ID based on references setting), refillInterval (number, optional, milliseconds), refillAmount (number, optional), lastRefillAt (Date, optional), enabled (boolean, optional), rateLimitEnabled (boolean, optional), rateLimitTimeWindow (number, optional, milliseconds), rateLimitMax (number, optional), requestCount (number, optional), remaining (number, optional), lastRequest (Date, optional), expiresAt (Date, optional), createdAt (Date), updatedAt (Date), permissions (string, optional), metadata (string, optional).

API Key schema migration from userId to referenceId

The userId field has been replaced with referenceId in a breaking change. API responses now return referenceId instead of userId. The owner type (user vs organization) is determined by the configuration's references setting, not stored on each key. Migration requires: adding config_id column with default 'default', adding reference_id column, copying userId to referenceId, making reference_id required, creating indexes on reference_id and config_id, and optionally dropping the old userId column.

Give your agent this brain