Skip to content

api_server

Various Pydantic models for information received from the API server.

PasswordPolicy pydantic-model

Bases: BaseModel

The server's password length policy for registration.

Exposed so the client validates and hints against the SAME bounds the server enforces, instead of hardcoding them (a tuned policy must never make the sign-up hint lie).

Fields:

max_length pydantic-field

Maximum password length accepted.

min_length pydantic-field

Minimum password length accepted.

PermissionInfo pydantic-model

Bases: BaseModel

One permission as the server knows it.

The vocabulary is served so that a client renders it instead of keeping a copy: an admin's permission editor lists exactly what the server can grant, and an API key dialog offers exactly what a key may carry.

Fields:

action pydantic-field

The part after the colon.

key_scopeable pydantic-field

Whether an API key may be scoped to this permission. Account and key management never are; the server decides the rest.

resource pydantic-field

The part before the colon.

value pydantic-field

The permission, resource:action.

ServerApiKeyLimits pydantic-model

Bases: BaseModel

The API-key policy a deployment enforces, for clients that create keys.

All zero means the server did not report it (older API).

Fields:

default_ttl_days = 0 pydantic-field

The lifetime applied when a request omits expires_in_days.

max_active_per_user = 0 pydantic-field

How many unexpired keys one account may hold at once.

max_ttl_days = 0 pydantic-field

The longest lifetime a key may be created with.

ServerBatchLimits pydantic-model

Bases: BaseModel

Maximum item counts accepted by the batch endpoints, per request.

The same numbers the request schemas state as maxItems, served so a client can read them at runtime without parsing the schema; the server enforces exactly these.

Fields:

max_analysis_status_ids pydantic-field

Max analysis IDs in one batch status poll

max_analysis_submissions pydantic-field

Max targets × pipeline steps in one batch analysis submission

max_cancel_analysis_ids pydantic-field

Max analysis IDs in one batch cancellation

max_channel_patches pydantic-field

Max patches in one bulk channel patch

max_event_analysis_ids pydantic-field

Max analysis IDs in one batch event retrieval

max_recording_detail_ids pydantic-field

Max recording IDs in one batch details retrieval

max_recordings_by_study_ids pydantic-field

Max study IDs in one batch recordings-by-study retrieval

max_studies pydantic-field

Max studies in one batch study creation

max_study_ids pydantic-field

Max study IDs in one batch studies-by-id retrieval

contract() classmethod

Return the caps as the request schemas state them.

ServerFeaturesEnabled pydantic-model

Bases: BaseModel

Global server features that are enabled or disabled.

Fields:

assignable_usage_types pydantic-field

Usage types that may be held by a user AT ALL, admins included — a superset of selectable_usage_types. Derived, not configured: a usage type is assignable only if a LICENCE DOCUMENT exists for it, because holding one means being gated onto that licence. CLINICAL is absent until a clinical licence is published. Admin UIs should offer exactly this list.

demo_datasets pydantic-field

Whether demo dataset registration is available (requires local storage backend)

email_verification pydantic-field

Whether email verification is enabled

login pydantic-field

Whether user login is enabled

password_policy pydantic-field

The password length policy the server enforces at registration — clients should validate/hint against these bounds rather than hardcoding them.

registration pydantic-field

Whether user registration is enabled

require_approval pydantic-field

Whether self-registrations require admin approval before login (request-access mode). When true, the client should frame sign-up as 'request access' and tell the user their account is pending after registering.

selectable_usage_types pydantic-field

Usage types a REGISTRANT may currently choose. A policy list — narrower than what may exist at all (see assignable_usage_types), e.g. COMMERCIAL is withheld from sign-up while it is offered by arrangement only. The client should grey out any UsageType not in this list; the server also rejects them.

submissions = True pydantic-field

Whether analyses may be submitted right now. As for uploads: a bounded, operator-set suspension, reported here so the submit surfaces can say so.

uploads = True pydantic-field

Whether recordings may be registered right now. An operator may suspend uploads platform-wide for a bounded time; a client that reads false should say so instead of offering the upload and expecting a refusal.

ServerLimits pydantic-model

Bases: BaseModel

Server request limits relevant to clients.

The batch caps are contract constants (the request schemas' maxItems); the upload ceilings are deployment configuration. Both are distinct from per-user usage quotas, which are exposed via /history/usage/limits.

Fields:

api_keys pydantic-field

The API-key lifetime and count policy in force.

batch pydantic-field

Per-request item caps for the batch endpoints

max_upload_bytes pydantic-field

Maximum size (bytes) of a single recording (register -> presigned PUT -> finalize). Clients should validate against this rather than hardcoding a cap a config change could invalidate.

recording_formats pydantic-field

The formats a recording may be uploaded in, matched on the file extension (the format's value, e.g. edf). Filter a file picker and validate against this rather than hardcoding a list; the server refuses any other format at registration.