Admin API Routes
Relevant source files
The following files were used as context for generating this wiki page:
Admin API Routes provide the private backend infrastructure required to manage the Inkweave platform. These routes execute privileged operations that are inaccessible to the general public application. The system functions as a secure administrative layer, separating management logic from the core user-facing features.
The administration tool integrates the main Inkweave application as a submodule. This structure allows the admin routes to interact directly with core logic and data structures while maintaining a distinct deployment environment. The entire API surface resides behind specialized authentication to prevent unauthorized access to sensitive platform controls.
Sources: README.md:1-5
System Architecture
The architecture of the Admin API routes relies on a wrapper pattern. The inkweave-admin repository acts as the host environment, while the upstream/inkweave submodule provides the primary application context.
Request Lifecycle
Administrative requests undergo strict validation before reaching the API logic. Because the application deploys to Vercel, it leverages platform-level security features to ensure that only authenticated staff members interact with the routes.
The diagram shows the flow of an administrative request through the mandatory Vercel authentication layer before interacting with the core submodule logic.
Sources: README.md:3-5, docs/PLAN.md
Authentication and Security
Security for Admin API routes is managed primarily at the deployment level. Unlike the public Inkweave application, the admin tool is restricted to internal users.
- Vercel Authentication: The project deploys behind a Vercel Login barrier. This ensures that the API endpoints are not reachable by the public internet.
- Private Repository: Source code and configuration for administrative routes remain in a private repository to protect internal tool logic.
- Environment Isolation: Admin routes typically use specific environment variables distinct from the production application to prevent cross-environment data contamination.
Sources: README.md:3-5, vercel.json
Submodule Integration
The Admin API routes utilize a submodule at upstream/inkweave to maintain parity with the core application. This allows developers to use the same data models and utility functions in the admin interface as those used in the public app.
Integration Components
| Component | Description | Reference Path |
|---|---|---|
| Core Submodule | The pinned version of the public Inkweave app. | upstream/inkweave |
| Design Plan | The roadmap for admin feature implementation. | docs/PLAN.md |
| Working Rules | Specific guidelines for development within this repo. | CLAUDE.md |
This diagram illustrates the dependency relationship where the Admin API routes consume definitions and services from the Inkweave Core submodule.
Sources: README.md:3-5, .gitmodules
Development Guidelines
Development of new API routes must adhere to the project's specific working rules. These rules ensure consistency across the administrative tools.
- Rule Adherence: Developers must follow the instructions defined in
CLAUDE.md. - Phase Management: New route implementation status is tracked in
docs/PLAN.md. - Upstream Syncing: API logic must remain compatible with the specific commit pinned in the
upstream/inkweavesubmodule.
Sources: README.md:7-8, CLAUDE.md, docs/PLAN.md
Summary
Admin API Routes serve as the secure backbone for Inkweave platform management. By combining Vercel-based authentication with a submodule-driven architecture, the system provides a robust and consistent environment for administrative tasks. This configuration ensures that internal management logic remains isolated from the public application while sharing essential core components.