browser/platform/api/routes.md

Platform API Route Catalog

Route declarations and handler comments live in platform/api. Request, response, list, and error contracts live in platform/dto; handlers must call platform/service.Core rather than repositories directly.

Implemented Core Resource Routes

All routes use JSON request and response bodies. Collection routes support GET for lists and POST for create. Detail routes support GET by ID. Unsupported methods return dto.ErrorResponse with 405.

Resource	Collection	Detail	DTO contracts
Users	GET /api/v1/users, POST /api/v1/users	GET /api/v1/users/{id}, PUT /api/v1/users/{id}	UserCreateRequest, UserUpdateRequest, UserResponse, UserListResponse
AI providers	GET /api/v1/ai-providers, POST /api/v1/ai-providers, POST /api/v1/ai/invocations, POST /api/v1/ai/config-suggestions	GET /api/v1/ai-providers/{id}, PUT /api/v1/ai-providers/{id}	AIProviderCreateRequest, AIProviderUpdateRequest, redacted AIProviderResponse, AIProviderListResponse, AIInvocationRequest, AIInvocationResponse, LlmConfigSuggestionRequest, LlmConfigSuggestionResponse
Game plugins	GET /api/v1/game-plugins, POST /api/v1/game-plugins	GET /api/v1/game-plugins/{id}	GamePluginCreateRequest, GamePluginResponse, GamePluginListResponse
Plugin marketplace	GET /api/v1/plugin-marketplace/plugins	GET /api/v1/plugin-marketplace/plugins/{id}, POST /api/v1/plugin-marketplace/plugins/{id}/state	MarketplacePluginResponse, MarketplacePluginListResponse, MarketplacePluginStateRequest
Plugin bridge	POST /api/v1/plugin-bridge/authorize, POST /api/v1/plugin-bridge/execute	n/a	PluginBridgeAuthorizeRequest, PluginBridgeAuthorizeResponse, PluginBridgeExecuteRequest, PluginBridgeExecuteResponse
Server instances	GET /api/v1/server-instances, POST /api/v1/server-instances	GET /api/v1/server-instances/{id}	ServerInstanceCreateRequest, ServerInstanceResponse, ServerInstanceListResponse
Metrics	GET /api/v1/metrics/platform, GET /api/v1/metrics/server-instances	n/a	PlatformResourceUsageResponse, ServerMetricsResponse, ServerMetricsListResponse
Server config	n/a	GET /api/v1/server-instances/{id}/config, POST /api/v1/server-instances/{id}/config/diff, POST /api/v1/server-instances/{id}/config/approve	ServerConfigResponse, ServerConfigDiffPreviewRequest, ServerConfigDiffPreviewResponse, ServerConfigWriteApprovalRequest, ServerConfigWriteDispatchResponse
File operations	POST /api/v1/file-operations/dispatch	n/a	FileOperationDispatchRequest, FileOperationDispatchResponse
Server administrators	GET /api/v1/server-instances/{id}/administrators/candidates, POST /api/v1/server-instances/{id}/administrators	DELETE /api/v1/server-instances/{id}/administrators/{userId}	ServerMemberRequest, ServerMemberResponse, ServerMemberListResponse, ServerInstanceResponse
Run endpoints	GET /api/v1/run/endpoints, POST /api/v1/run/endpoints	GET /api/v1/run/endpoints/{id}	RunEndpointCreateRequest, RunEndpointResponse, RunEndpointListResponse
Jobs	GET /api/v1/jobs, POST /api/v1/jobs	GET /api/v1/jobs/{id}	JobCreateRequest, JobResponse, JobListResponse
Artifacts	GET /api/v1/artifacts, POST /api/v1/artifacts	GET /api/v1/artifacts/{id}, POST /api/v1/artifacts/{id}/download, GET /api/v1/artifacts/{id}/content	ArtifactCreateRequest, ArtifactResponse, ArtifactListResponse, ArtifactDownloadReferenceResponse, ArtifactContentRequest
Log streams	GET /api/v1/log-streams, POST /api/v1/log-streams	GET /api/v1/log-streams/{id}	LogStreamCreateRequest, LogStreamResponse, LogStreamListResponse
Audit events	GET /api/v1/audit-events, POST /api/v1/audit-events	GET /api/v1/audit-events/{id}	AuditEventCreateRequest, AuditEventResponse, AuditEventListResponse

Implemented Query Filters

• GET /api/v1/users?status=active
• GET /api/v1/ai-providers?kind=openai&status=active
• GET /api/v1/game-plugins?serverType=scum&status=installed
• GET /api/v1/plugin-marketplace/plugins?serverType=scum&status=installed&capability=logs.read&keyword=scum
• GET /api/v1/server-instances?pluginId=server.scum&runEndpointId=run-local&state=draft
• GET /api/v1/metrics/server-instances
• GET /api/v1/run/endpoints?status=online
• GET /api/v1/jobs?serverInstanceId=server-1&runEndpointId=run-local&state=queued
• GET /api/v1/artifacts?ownerKind=job&ownerId=job-1&state=uploading
• GET /api/v1/log-streams?serverInstanceId=server-1&streamKey=stdout
• GET /api/v1/audit-events?actorId=user-1&resourceKind=server-instance&resourceId=server-1&result=success

Implemented Authentication And Current User Actions

• POST /api/v1/auth/register: accept RegisterRequest; the first registered account becomes an active platform administrator with an authenticated session, while later registrations create pending low-privilege users and return AuthSessionResponse with status=pending and no session token.
• POST /api/v1/auth/login: accept LoginRequest, authenticate an active user by ID or email, and return AuthSessionResponse with a bearer session token.
• POST /api/v1/auth/logout: invalidate the active bearer session token and return 204.
• GET /api/v1/users/current: return CurrentUserResponse for the bearer session.
• PUT /api/v1/users/current/profile: update bounded current-user profile fields using UserProfileBody.
• PUT /api/v1/users/current/theme: persist current-user console theme preferences using UserThemePreferenceRequest.

Auth responses never expose password hashes or raw credentials. After the first account exists, public registration defaults to pending plus server-scoped roles and does not grant platform administrator privileges. Tests and local fixtures may seed one explicit platform administrator account for manual login: operator.local@example.test / operator-local.

Implemented Role-Scoped Server Access

• User-facing server instance list, detail, create, and lifecycle routes require a bearer session.
• Platform administrators can view and manage all server instances.
• Server owners and server administrators can only view and manage server instances they own or administer.
• Server instance responses include bounded ownerUserId and adminUserIds membership metadata.
• GET /api/v1/server-instances/{id}/administrators/candidates: lets the server owner list active non-platform-admin users that can be invited.
• POST /api/v1/server-instances/{id}/administrators: lets the server owner invite an active non-platform-admin user using ServerMemberRequest.
• DELETE /api/v1/server-instances/{id}/administrators/{userId}: lets the server owner remove a server-scoped administrator. The route never deletes the user account.

Server owner membership actions hide and reject platform administrators. Server administrators cannot invite or remove administrators unless they also own the target server.

Implemented Observability And Config Read Actions

• GET /api/v1/metrics/platform: returns bounded platform CPU, memory, disk, source, and timestamp metadata for platform administrators.
• GET /api/v1/metrics/server-instances: returns bounded per-server metrics only for server instances visible to the authenticated user.
• GET /api/v1/server-instances/{id}/config: returns logical server config content, format, key, config version, and update timestamp for an authorized server instance.

Observability and config read responses are read-only. They do not expose host filesystem paths, raw credentials, direct run sockets, storage backend credentials, raw AI provider keys, or run session tokens.

Implemented Config Write And File Dispatch Actions

• POST /api/v1/server-instances/{id}/config/diff: accepts ServerConfigDiffPreviewRequest, validates server access, expected config version, logical config key, bounded proposed content, and returns a platform-computed ServerConfigDiffPreviewResponse without creating a run job.
• POST /api/v1/server-instances/{id}/config/approve: accepts ServerConfigWriteApprovalRequest, revalidates the reviewed diff, rejects stale/no-change/unsafe writes, and queues a scoped config.write job using ServerConfigWriteDispatchResponse.
• POST /api/v1/file-operations/dispatch: accepts FileOperationDispatchRequest, validates server visibility plus optional plugin permissions, rejects unsafe targets, and queues files.read or files.write jobs using logical keys and refs.

Config write and file dispatch responses expose only logical target keys, scoped input/artifact refs, and bounded job metadata. They do not expose host filesystem paths, raw credentials, direct sockets, run session tokens, raw AI provider keys, or inline large file contents.

Implemented AI Provider Management Actions

• POST /api/v1/ai-providers/{id}/status: enable or disable one provider using AIProviderStatusRequest.
• POST /api/v1/ai-providers/{id}/test: run local metadata validation using AIProviderTestResponse; this does not call external AI services.
• GET /api/v1/ai-providers/{id}/models: return configured model names using AIProviderModelsResponse.
• POST /api/v1/ai/invocations: accept AIInvocationRequest, authorize explicit purposes, select an active provider, invoke a mockable provider client, and return AIInvocationResponse with bounded recommendation text, usage metadata, optional reviewable config recommendation, and safe errors.
• POST /api/v1/ai/config-suggestions: compatibility route for console config assistance. It uses the mediated invocation service with purpose=config.suggest and returns LlmConfigSuggestionResponse for the existing review/approval workflow.

AI invocation is platform-mediated. Tests and local verification use a deterministic mock provider client; live external provider calls are deferred behind the same interface and are not required for this change. Invocation responses do not expose provider base URLs, API key refs, raw keys, bearer tokens, host paths, run sockets, or storage credentials. Config suggestions are recommendations only and never dispatch run-side writes directly.

Implemented Game Plugin Registry Actions

• POST /api/v1/game-plugins/register-manifest: accept GamePluginManifestRegistrationRequest, validate a game management plugin manifest, and persist installed registry metadata using GamePluginResponse.

Plugin registry responses include identity, description, version, server type/display metadata, manifest and create-form schema references, required run capabilities, declared scoped permissions, aggregate platform permissions, lifecycle action references, plugin pages, tags, AI purposes, validation violations for invalid records, and install status. They do not expose raw host paths, raw credentials, direct run sockets, or raw AI provider keys.

Implemented Plugin Marketplace Actions

• GET /api/v1/plugin-marketplace/plugins: list bounded marketplace plugin summaries projected from installed registry metadata. Optional filters include status, serverType, capability, and keyword.
• GET /api/v1/plugin-marketplace/plugins/{id}: return one marketplace plugin detail using manifest-backed registry metadata.
• POST /api/v1/plugin-marketplace/plugins/{id}/state: accept MarketplacePluginStateRequest with install, enable, or disable and update registry install state only.

Marketplace responses include game management plugin identity, version, display metadata, server type, installed state, capabilities, pages, permissions, tags, AI purposes, and validation violations. They are a platform registry projection, not a commerce catalog, and they do not include billing, pricing, ratings, reviews, cloud host sales, raw credentials, host paths, direct run sockets, package bytes, or raw AI provider keys.

Marketplace state actions are metadata-only in this change. install and enable mark the registered plugin installed; disable marks it disabled. These actions do not download external packages, create run jobs, execute plugin code, write files, or contact external services.

Implemented Plugin Bridge Actions

• POST /api/v1/plugin-bridge/authorize: accepts PluginBridgeAuthorizeRequest and returns whether an installed plugin page may use one declared bridge action with the effective route permissions.
• POST /api/v1/plugin-bridge/execute: accepts PluginBridgeExecuteRequest, repeats backend validation and authorization, and executes only mapped platform-mediated actions. Supported execution currently includes server context reads, lifecycle job dispatch for declared run capabilities, log cursor metadata queries, scoped file dispatch, artifact open references, and platform-mediated AI invocation.

Bridge execution responses are typed envelopes with requestId, plugin/page/server scope, action, status, result refs, and safe error codes. They do not expose bearer tokens, run sockets, host filesystem paths, raw credentials, storage backend credentials, provider base URLs, raw AI provider keys, or unbounded file/log contents.

Artifact bridge execution returns safe metadata and platform content routes only. It does not return artifact bytes through the bridge message and does not expose run endpoints, storage adapter paths, presigned backend URLs, host paths, or credentials.

Implemented Server Lifecycle Actions

• POST /api/v1/server-instances/workflows/create: accept ServerLifecycleCreateRequest, validate plugin/run dependencies and idempotency, create an installing server instance, and queue a process.install job using ServerLifecycleResponse.
• POST /api/v1/server-instances/{id}/start: accept ServerLifecycleCommandRequest, validate state/config version/run capability, and queue a process.start job using ServerLifecycleResponse.
• POST /api/v1/server-instances/{id}/stop: accept ServerLifecycleCommandRequest, validate state/config version/run capability, and queue a process.stop job using ServerLifecycleResponse.

Lifecycle workflow responses include accepted status, action, bounded server instance metadata, and bounded job metadata. They do not expose run credentials, host paths, raw credentials, AI provider keys, direct sockets, plugin action file contents, or large result bodies.

Implemented Run Control Actions

• POST /api/v1/run/control/hello: accept RunControlHelloRequest, create or update run endpoint metadata, and return RunControlHelloResponse with a platform-issued session token.
• POST /api/v1/run/control/heartbeat: accept RunControlHeartbeatRequest, require the active session token, update heartbeat metadata, and return RunControlHeartbeatResponse with the next heartbeat hint and optional capability refresh request.

Run control actions carry only lightweight metadata: endpoint ID, display name, version, status, capability fingerprint/list, capacity, session token, and timing hints. They do not carry job bodies, logs, artifact chunks, host paths, raw credentials, or direct sockets. Control is the highest-priority run-facing channel; artifact/file transfer pressure must not delay heartbeat processing or mutate endpoint capacity through heavy payload fields.

Implemented Run Job Actions

• POST /api/v1/run/jobs/claim: accept RunJobClaimRequest, validate the active run session, lease one queued job for that endpoint, and return RunJobClaimResponse.
• POST /api/v1/run/jobs/ack: accept RunJobAckRequest and move an active leased job into running state.
• POST /api/v1/run/jobs/progress: accept RunJobProgressRequest and update bounded progress metadata.
• POST /api/v1/run/jobs/result: accept RunJobResultRequest and write an idempotent terminal job result.
• POST /api/v1/run/jobs/cancel: accept RunJobCancelPollRequest and return pending cancellation metadata for active leases.
• POST /api/v1/run/jobs/reconcile: accept RunJobReconcileRequest and return platform-known active jobs plus unknown run-reported job IDs.
• POST /api/v1/jobs/{id}/cancel: accept RunJobCancelRequestBody and record a platform cancellation request for run polling.

Run job actions carry bounded job metadata only: job ID, run endpoint ID, server instance ID, capability, idempotency key, lease token, attempt, progress, terminal state, message, error code, result reference, and timing hints. They do not carry logs, artifact chunks, host paths, raw credentials, direct sockets, or large inline result bodies. Job ack/progress/result/cancel/reconcile calls remain lightweight and independently valid while log batches or artifact/file chunks are queued, slow, or retrying. Equivalent duplicate terminal results remain idempotent under channel pressure.

Implemented Log Ingest Actions

• POST /api/v1/run/logs/batches: accept LogBatchIngestRequest, validate run session and stream metadata, store contiguous entries, update LogStream.LatestSeq, and return LogBatchIngestResponse with the acknowledged range.
• POST /api/v1/log-streams/query: accept LogStreamCursorRequest and return LogStreamCursorResponse with bounded ordered entries after a cursor.

Log ingest actions carry durable log metadata and bounded entries only: run endpoint ID, session token, stream identity, source, sequence range, compression metadata, checksum, entries, and cursor limits. They do not carry artifact chunks, host paths, raw credentials, direct sockets, or unbounded inline data. Log ingest is durable and independently retried. Artifact/file transfer backlog must not prevent log acknowledgement, duplicate acknowledgement, cursor state updates, or spool cleanup.

Platform storage is configured by PLATFORM_STORAGE_BACKEND. The default file backend writes metadata snapshots to PLATFORM_METADATA_PATH and log bodies to segmented files in PLATFORM_LOG_DIR; memory remains available for tests and ephemeral local runs. Relational stores such as MySQL/Postgres are reserved for metadata, stream cursors, indexes, retention state, and audit trails. High-volume log bodies for hundreds or thousands of servers should use a log-optimized backend behind LogBodyStore, such as ClickHouse, Loki, OpenSearch/Elasticsearch, or object-storage segments.

Implemented Run Artifact Actions

• POST /api/v1/run/artifacts/open: accept ArtifactTransferOpenRequest, validate active run session and scoped artifact owner, create or reuse uploading artifact metadata, and return ArtifactTransferOpenResponse with transfer resume state.
• POST /api/v1/run/artifacts/chunks: accept ArtifactChunkUploadRequest, validate chunk range and checksum, store idempotent chunk state, and return ArtifactChunkUploadResponse with acknowledged chunk indexes.
• POST /api/v1/run/artifacts/status: accept ArtifactTransferStatusRequest and return ArtifactTransferStatusResponse with received chunks and next missing chunk index.
• POST /api/v1/run/artifacts/complete: accept ArtifactTransferCompleteRequest, verify all chunks and final checksum, mark the artifact available, and return ArtifactTransferCompleteResponse.

Run artifact actions carry bounded upload metadata and chunk payloads only: run endpoint ID, session token, transfer ID, artifact ID, owner metadata, chunk indexes, byte ranges, checksums, and JSON chunk payload bytes. They do not carry control heartbeat metadata beyond session identity, job result bodies, logs, host paths, raw credentials, direct sockets, or plugin/browser storage credentials. Artifact/file transfer is lower priority than control, job lifecycle metadata, and durable log ingest. Slow or retrying chunks must not block heartbeat, job ack/result delivery, cancellation/reconcile calls, or log batch acknowledgement; lightweight routes reject heavy transfer payloads rather than storing them.

Implemented Browser Artifact Download Actions

• GET /api/v1/artifacts/{id}: returns authorized artifact metadata for the current bearer session.
• POST /api/v1/artifacts/{id}/download: returns ArtifactDownloadReferenceResponse with filename, content type, size, checksum, expiry, supported chunk size, and a platform-owned downloadUrl.
• GET /api/v1/artifacts/{id}/content: returns a bounded byte range using offset/limit query parameters or a Range: bytes=start-end header. Responses include Content-Length, Accept-Ranges, optional Content-Range, X-Artifact-Checksum, X-Artifact-Content-Checksum, and X-Artifact-Storage headers.

Browser artifact downloads require an available artifact plus user access to the owning job/server context. Platform/plugin-owned artifacts are limited to platform administrators until a future storage policy adds narrower ownership. Current content reads reconstruct completed upload chunks from the in-memory platform transfer session; durable external storage adapters are deferred behind the same service contract. Browser and plugin pages receive only platform routes and integrity metadata, never raw storage backend URLs, host paths, direct run sockets, run tokens, bearer tokens, or storage credentials.

Error Contract

API errors use dto.ErrorResponse:

• 400: malformed JSON or validation failure.
• 401: missing or invalid bearer session token.
• 403: valid credentials for an account that is pending, disabled, or otherwise forbidden.
• 404: missing resource or missing dependency reported by the service layer.
• 409: duplicate resource ID.
• 405: unsupported method on an implemented route.
• 500: unexpected platform error.

Deferred Route Groups

These route groups remain documented future work beyond the currently implemented routes:

• Authorization policy routes beyond role-scoped navigation and bearer session identity.
• Run control transport beyond hello and heartbeat, including heartbeat reconciliation policies.
• External metrics collectors, browser tail transport, external log body backends, and AI log analysis windows.
• Browser artifact upload, external artifact storage backends, presigned URLs, and production throttling policies.
• Plugin page iframe packaging and remote hosting policies beyond SDK-mediated bridge contracts.
• Live AI provider connectivity tests and remote model discovery.
• Server restart/update/delete routes.

Core Service Boundary

• platform/service.Core owns create/list/get workflows and cross-resource invariants.
• platform/repo.Store owns repository access and currently has a durable file-backed implementation for local startup plus an in-memory implementation for tests.
• platform/validator owns local resource validation and dependency compatibility checks.
• Handlers must never expose run credentials, host paths, or raw AI provider keys.