Command Center API — Business Requirements Document
Version: 1.4
Date: September 2026
Author: Pete Carroll, Founder — Traxs Group LLC
Status: Draft - Updated
Product: Command Center API — Traxs Group Platform API
URL: api.traxsgroup.com
1. Executive Summary
The Command Center API is the platform backbone of the Traxs One Suite. It serves as the integration layer between all Traxs products, handles public-facing communication (contact forms, support requests), and will grow into the central hub for cross-product data sharing, unified billing, entitlement, subscription and AI inference routing.
It is not a customer-facing product. It has no UI. It is infrastructure — the connective tissue that makes three independent products feel like one suite.
Update 2026-08-24 The System Admin App will connect to the Command Center API and the Keystone API.
See ADR-007 for the full decision record on why a separate Platform API was built rather than adding these capabilities to the RoundTrip API.
2. Problem Statement
2.1 The Integration Problem
As Traxs Group grows from one product to three, several cross-cutting concerns arise that cannot belong to any single product:
- Contact forms —
traxsgroup.comandroundtrips.appneed to accept contact form submissions and route them to SendGrid without exposing API keys to the browser - Cross-product data sharing — Waypoint's Executive Dashboard needs RoundTrip revenue data; Relay will need RoundTrip client data. Relay will need Waypoint data. Neither product should call the other's API directly
- Suite subscription awareness — the suite navigation switcher needs to know which products a tenant has active subscriptions to. Command Center will also control the customer's subscription entitlements.
- Unified billing — as customers subscribe to multiple products, a single billing hub prevents fragmented Stripe customer records
2.2 The "No Mailto" Requirement
Every Traxs web property must accept contact form submissions through a proper API — no mailto: links that open the user's email client. This requires a server-side endpoint that can receive form data, validate it, and route it to SendGrid without exposing credentials to the browser.
2.3 The Cross-Product Data Problem
Without a dedicated integration layer, products would need to call each other's APIs directly — creating tight coupling. If RoundTrip's API changes, Waypoint breaks. The Command Center API solves this by acting as a stable integration contract between products.
3. Business Objectives
| Objective | Metric | Target |
|---|---|---|
| Eliminate all mailto links across Traxs web properties | Count of mailto: links on live sites | 0 |
| Subscriptions | handles which subscription a tenant is on | By Keystone launch |
| Product Entitlements | handles what products a tenant are entitled to | By Keystone launch |
| Enable Waypoint Executive Dashboard RoundTrip integration | Dashboard shows RT revenue on day one | By Waypoint M7 |
| Support suite navigation across all products | Suite switcher shows correct products | By Waypoint launch |
| Provide stable integration contract between products | Zero breaking changes to existing endpoints | Always |
| Enable unified Stripe customer management | One Stripe customer per Traxs tenant | By Waypoint billing launch |
4. Stakeholders
| Role | Person | Interest |
|---|---|---|
| Owner / Architect | Pete Carroll | All decisions |
| Consumer — RoundTrip | RoundTrip API | Publishes data via Command Center |
| Consumer — Waypoint | Waypoint API | Consumes RoundTrip data via Command Center |
| Consumer — Marketing site | roundtrips.app (Astro) | Contact form submission |
| Consumer — Company site | traxsgroup.com (React) | Contact form submission |
| Consumer — Future Relay | Relay API | CRM data exchange |
5. Scope
5.1 Current Scope (Live as of July 2026)
| Endpoint | Purpose | Status |
|---|---|---|
POST /v1/contact | Contact form → SendGrid | ✅ Live |
POST /v1/support | Support requests → SendGrid + Crisp | ⏳ Planned |
POST /v1/feedback | In-app feedback → SendGrid | ⏳ Planned |
GET /health | Health check | ✅ Live |
5.2 Subscription Scope (Needed now — see command-center-framing.md §8)
Endpoint shapes below are grounded in the settled schema (command-center-database.md v2.2) — one Subscription row per (Tenant, Product), written by Command Center's own Stripe webhook dispatcher (see command-center-stripe-migration.md).
| Endpoint | Purpose | Consumer |
|---|---|---|
GET /v1/subscriptions?tenantId={id} | Returns all of a tenant's subscriptions — product, tier, status, trial/cancellation dates | Product frontends (suite switcher), admin app |
Creating and updating a Subscription are no longer public HTTP endpoints, as of command-center-stripe-migration.md (2026-09-16) — with Stripe processing centralized into Command Center, there's no remaining external caller for them. Both are now internal commands invoked directly by Command Center's own Stripe webhook dispatcher (POST /v1/billing/webhook), not endpoints any product calls.
5.3 Product Entitlement Scope (Needed now — see command-center-framing.md §8)
| Endpoint | Purpose | Consumer |
|---|---|---|
GET /v1/entitlements?tenantId={id} | Per product: whether the tenant is currently entitled (derived from subscription status, not a separate stored flag), current tier, and effective price (accounting for any active Founders-Program-style rate lock) | Keystone's entitlement-check call, product APIs |
5.4 Near-Term Scope (Waypoint Launch)
| Endpoint | Purpose | Consumer |
|---|---|---|
GET /v1/roundtrip/revenue-summary | RoundTrip revenue data for Waypoint dashboard | Waypoint API |
GET /v1/roundtrip/tickets/open | Open ticket summary for Waypoint dashboard | Waypoint API |
GET /v1/roundtrip/invoices/recent | Recent invoices for Waypoint dashboard | Waypoint API |
GET /v1/roundtrip/team | Technician list for Waypoint team view | Waypoint API |
GET /v1/roundtrip/ar/aging | AR aging data for Waypoint financial view | Waypoint API |
GET /v1/suite/subscriptions | Which products does this tenant have? | All product frontends |
POST /v1/clients/sync | Cross-product client record sync | RoundTrip → Waypoint |
5.5 Future Scope (Relay Launch)
| Endpoint | Purpose |
|---|---|
POST /v1/relay/lead | RoundTrip → Relay lead creation |
POST /v1/roundtrip/client | Relay → RoundTrip client creation |
| Campaign trigger events | RoundTrip job complete → Relay follow-up |
5.6 Long-Term Vision
| Capability | Description |
|---|---|
| Unified billing hub | Stripe customer shared across products — one billing record per tenant |
| Webhook management | Products publish events, others subscribe |
| AI inference gateway | Routes requests to Anthropic API — shared across all products |
| Platform analytics | Cross-product usage data for owner dashboard |
6. Non-Functional Requirements
| Requirement | Target |
|---|---|
| Availability | 99.5% uptime |
| Response time | < 500ms for all endpoints (excluding external API calls) |
| Security | All service-to-service calls authenticated via API key |
| Public endpoints | Contact/support/feedback endpoints are unauthenticated (rate limited) |
| Rate limiting | Public endpoints: 10 requests/minute per IP |
| CORS | Configured per endpoint — public endpoints allow Traxs domains only |
7. Constraints
- No database in the initial v1 build — that build was scoped to the email service for
traxsgroup.comalone, pure pass-through to SendGrid, RoundTrip API, and Crisp. A database has always been the plan for what comes next, not a permanent constraint — see Section 3's Subscriptions/Product Entitlements objectives andcommand-center-framing.md§7 for what's needed now. - Same Clean Architecture as RoundTrip — any developer can navigate immediately
- Deployed on Azure App Service (Central US) — same region as RoundTrip
- Must never become a bottleneck — if Command Center API is down, products must degrade gracefully
8. Open Notes
Entitlement delegation and subscription ownership are no longer open questions in the abstract — both are Command Center's responsibility, delegated from Keystone (keystone-framing.md §9). The narrower, more structural question underneath both — who owns the canonical Tenant/Account concept — is now decided: Command Center owns it, seeded from RoundTrip's existing TenantId on day one. Ratified by Pete, 2026-09-03. See command-center-framing.md §5/§6 for the full reasoning and §7 for the field-level detail.
9. Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | July 2026 | Pete Carroll | Initial draft |
| 1.1 | August 2026 | Pete Carroll | Draft - Updated |
| 1.2 | September 2026 | Pete Carroll (with Claude) | Reworded Section 7's database constraint to reflect it always described v1's initial scope, not a permanent limit. Replaced the unfinished "Some notes" section with a pointer to command-center-framing.md, where the real open question (Tenant/Account ownership) is now tracked. |
| 1.3 | September 2026 | Pete Carroll (with Claude) | Updated Section 8 — Tenant/Account ownership ratified (Command Center owns canonical Tenant, seeded from RoundTrip's TenantId on day one). |
| 1.4 | September 2026 | Pete Carroll (with Claude) | Filled in Sections 5.2/5.3 — were broken stub tables with no real endpoint shapes. Now grounded in the settled schema (command-center-database.md v2.1): subscription CRUD endpoints and a real GET /v1/entitlements shape, both pointed at command-center-framing.md §8's "needed now" list rather than a vague "Keystone launch" label. |