Build your app on ProjexCloud

Get access — API key + base URL

Sign in to ProjexCloud at cloud.projexlight.com, open Tenant Admin → API keys, create an application (one per backend, job or environment) and issue a key under it. You now have the two things every call needs: the base URL (https://cloud.projexlight.com) and a machine credential. Pass the key as Authorization: Bearer pk_live_… on every request, or exchange it once for a short-lived token at POST /api/auth/token and send that instead — both work on every tenant route. No account for ProjexLight is required.

Download the SDK catalog

Download sdk-catalog.json ↓ — the machine-readable catalog: every SDK, its group, and each endpoint (method, path, auth, payload shape, field enums, dependencies) for all 680 APIs. Browse the same content human-style in the API reference. Drop the catalog straight into your repo — it's the exact catalog ProjexLight bundles, just consumed directly.

The same bundle also ships openapi.json (OpenAPI 3.1, 608 tenant-callable operations — point any client generator at it), sdk-catalog-index.json (the compact map an AI builder loads first), and AGENTS.md — the agent-facing brief carrying the authentication flows and the rules that stop an agent rebuilding identity. Start with Authentication & Identity if you are wiring signup, login or API keys.

Point your AI coding tool at the catalog

In your own repo, attach sdk-catalog.json (or the API-reference URL) as context for Claude Code, Cursor, Aider, Windsurf, or Goose, and instruct it:

"Use the ProjexCloud SDK catalog. Before writing any backend, service, or
 data model, check whether an SDK already covers it — if so, call the gateway
 at https://cloud.projexlight.com/api/… with the tenant JWT instead of building it.
 Only generate custom code for capabilities no SDK provides."

The model discovers all 680 APIs from the catalog and reuses them — the same reuse rule ProjexLight ships, applied inside your own tool. (Optional: serve the catalog over a local MCP so it's a tool call, not just pasted context.)

Call the gateway — that's the whole integration

Every SDK is a REST call to your base URL with the tenant JWT:

curl -X POST https://cloud.projexlight.com/api/scheduling/appointments \
  -H "Authorization: Bearer $TENANT_JWT" \
  -H "Content-Type: application/json" \
  -d '{ "persona_id": "…", "start": "2026-08-01T15:00:00Z", "duration_min": 30 }'

Gated, metered, audited, and isolated to your tenant's pool automatically. Your app stores only its own domain data and references canonical IDs (person_id, persona_id) — see Your data vs ours. Nothing to deploy or maintain on the ProjexCloud side.

Create a project in ProjexLight

Sign up at projexlight.com and grab your API key. Create a Project (name + description), then walk the Project Refinement Wizard — a 15-step guided flow (idea, audience, core features, tech stack, data model, APIs & integrations, timeline…) that turns a short brief into a full PRD. This is where your app is scoped.

Opt in to ProjexCloud SDKs — one checkbox

In the CLI Export Wizard (or the Quick Prototype wizard) tick "Reuse ProjexCloud pre-built SDKs." Off by default = standalone (generate everything). When on, code generation reuses ProjexCloud's 469 tenant-callable APIs (identity, CRM, scheduling, billing, notifications…) instead of building those backends. The choice is saved as useProjexCloudSdks, persisted to your project, and reversible. Unsure? Read Why pre-built SDKs?

Prototype note: a prototype generated with this on skips building identity/auth/APIs — so it promotes cleanly to a full sprint (the choice carries over automatically). Platform-admin APIs are excluded from the reuse set (they need an operator token, not your tenant token).

CLI export — download your scaffold & add your key

From the wizard, download the export ZIP: a self-contained scaffold with .claude/instructions/bootstrap.md, .projexlight/context/*, the mcp-server/ toolkit, and — when you opted in — the bundled SDK catalog (mcp-server/data/sdk-catalog.json + the ~3k-token sdk-catalog-index.json map) and a .env.example pre-wired with PROJEXCLOUD_API_BASE_URL + a blank PROJEXCLOUD_TENANT_TOKEN.

Copy .env.example → .env and paste your tenant token from cloud.projexlight.com/workspace → Settings → API keys. (That's the only step that uses ProjexCloud's own portal.)

Start the Dev & Test MCP servers

One command sets up everything — the code-generation guidance server, the API/UI test server, and your app's database:

cd mcp-server
./setup-all.sh                      # Dev-MCP + Test-MCP + DB containers, git hooks, project registration
curl http://localhost:8766/health   # Dev MCP  (code-gen standards + SDK catalog)
curl http://localhost:8000/health   # Test MCP (API + BDD/UI tests)

Idempotent & smart — re-run any time. Up to 4 projects share one MCP set. Manage with ./setup-all.sh --status.

Generate the code — the build loop

Open your AI coding tool and prompt: "Read .claude/instructions/bootstrap.md and start." The agent then loops, task by task:

init_session      → your assigned tasks for the sprint
get_instruction   → next task's context. If you opted in AND it's a backend task, a
                    REUSE-FIRST rule is injected:
  ├─ scan the ~3k-token SDK map (sdk-catalog-index.json) ONCE, keep it in context
  ├─ match your capability via reuse_when keywords → pick an SDK/endpoint
  ├─ call the get_sdk_api tool for THAT one endpoint's spec (payload/fields) — never
  │     the whole 94k-token catalog
  └─ call the gateway at $PROJEXCLOUD_API_BASE_URL/api/… with the tenant token — don't rebuild
(otherwise generate from scratch; write the API-definition JSON first)
validate / self_check / quality_gates   → Dev-MCP reviews vs standards + auto-fixes
complete_task     → only when validation.passed === true
… repeat until the sprint is done

Progressive disclosure keeps tokens low: the SDK map is read once per session; only the endpoints you actually use are fetched in full via get_sdk_api.

Manage the work — Epics → Features → Scenarios → Tasks

Your project is organized as a hierarchy, authored in the portal or via MCP tools:

• Epic — a major capability area.
• Feature — a shippable unit (with a Background).
• Scenario — a Gherkin BDD spec (Given/When/Then) that becomes UI/behavior tests.
• Task — the unit an AI session completes (backend / frontend / service / database / testing).

Bulk-manage with import_full / import_epics / create_tasks_bulk / create_scenario; getters like get_features_by_epic, get_tasks_by_feature.

Sprints & multiple developers

Work ships per sprint (each export adds new epics/tasks on a new git branch, preserving prior code). Every developer runs their own CLI export + setup-all.sh against the shared MCP set; init_session returns each developer's own task list (resolved by taskId). A live leaderboard tracks lines, compliance score, and violations fixed per developer per day.