Platform Surface Map

console.sophosic.ai

Stripe ConnectOK

GoogleOK

GET /healthPOST /forms

Integration consoleAccess posture, API families, webhooks, and connected provider status

This page maps the console and sites surfaces that operators, implementers, and support teams use most often. Use it to decide where a workflow belongs, which app owns it, and which route family should be inspected when behavior looks wrong.

Reference Scope

This is not a complete external developer API contract. It is an operator and implementation map for understanding which app owns each workflow surface, which routes are customer-facing, and which routes are internal control planes.

Console Surfaces

Console pages are operator surfaces. They manage configuration, content, customer work, integrations, and launch decisions for the selected workspace.

Workspace setupRoutes

/: Workspace picker

/get-started: Setup guidance

/settings/*: Workspace configuration

/settings/integrations/*: Third-party integrations

Daily operationsRoutes

/insights: Workspace performance summary

/scheduling: Bookings, services, availability, and calendar sync

/customers: Customer records and relationship history

/inbox: Customer events, messages, and form submissions

Commerce and fulfillmentRoutes

/shop: Products and catalog setup

/shop/orders: Sales, orders, transactions, and invoices

/shop/payments: Stripe dashboard and connected account state

/shipping: Fulfillment, labels, packages, zones, and rates

Content and growthRoutes

/website: Site editor handoff

/stories: Editorial content

/discovery: SEO, GEO, redirects, and short links

/communications: Email notifications

/forms: Form builder

Console Route Families

Console route families are internal operator APIs. They should be protected by operator session, selected workspace, membership, role, and tenant checks.

/api/editor/session

Editor session

Owns: Operator handoff and editor auth state

/api/editor/branding

Branding

Owns: Logo, theme, media, brand migration state

/api/editor/pages

Pages

Owns: Page drafts, publishing, site content

/api/editor/shop

Shop

Owns: Product catalog setup and commerce readiness

/api/editor/bookings/services

Bookings

Owns: Services, availability, booking setup state

/api/editor/discovery/seo*

Discovery

Owns: SEO, search posture, redirects, GEO content

/api/domains/verify

Domains

Owns: Domain verification and DNS diagnostics

/api/admin/reviews/{verb}

Admin reviews

Owns: Reputation operations and review sync actions

/api/admin/google-business/{verb}

Google Business

Owns: Google Business Profile connection actions

/api/internal/*

Internal maintenance

Owns: Background repair, drains, sync, reconciliation

Do not expose console route families as public integration points unless the product creates a supported public API wrapper around them.

Sites Public Surfaces

Sites pages are customer-facing surfaces. They render the public site, customer purchase paths, booking paths, forms, help, policies, stories, and portal entry points.

/{site}: Homepage
/{site}/shop: Product catalog
/{site}/shop/{productSlug}: Product detail
/{site}/cart: Cart
/{site}/checkout: Checkout
/{site}/bookings: Service list
/{site}/bookings/{serviceSlug}: Service detail and booking steps
/{site}/forms/{formSlug}: Public form
/{site}/help: Help center
/{site}/kb: Knowledge articles
/{site}/stories: Editorial content
/{site}/policies: Public policies
/{site}/contact: Contact page

Sites Technical Surfaces

Technical public routes support crawling, previews, auth handoff, unlock states, and search discovery.

/{site}/robots.txt: Search crawler rules for the workspace site
/{site}/sitemap.xml: Public URL inventory for search engines
/{site}/llms.txt: Workspace content summary for AI crawler consumption where enabled
/{site}/indexnow: Search engine update signal
/{site}/og-image: Social preview image for the workspace site
/{site}/login: Customer login entry
/{site}/unlock: Protected site unlock flow
/auth/callback: Auth callback
/portal/callback: Customer portal callback
/api/health: Sites health probe
/api/routing-test: Routing diagnostic probe

When previews or crawlers look wrong, verify the technical surface for the final domain, not a preview host.

Sites Customer Portal

Customer portal routes require a customer session or a scoped customer-management token. Use them to verify that public self-service is tenant-scoped, that guest orders or bookings can be claimed only by the right customer, and that sensitive billing, ticket, and profile data never appears on unauthenticated public pages.

/{site}/account: Customer account overview
/{site}/account/my-bookings: Customer booking history
/{site}/orders: Order history
/{site}/billing: Billing and subscriptions
/{site}/tickets: Support tickets
/{site}/profile: Profile and notifications
/{site}/saved: Saved items

Customer API Map

The sites app exposes customer API families for public and portal workflows. These routes are tenant-scoped through the site or workspace resolution layer and should validate ownership before returning private customer records.

Bookings and checkoutPublic or scoped

GET /api/v1/bookings/services exposes bookable services and available times.

POST /api/v1/bookings creates and manages customer bookings with customer session or scoped manage-token checks where private.

POST /api/v1/bookings/{id}/checkout handles deposits, final payment, and booking payment continuation.

POST /api/v1/cart/validate validates cart totals, coupons, shipping, and payment continuation.

POST /api/v1/checkout/paypal/status supports PayPal-specific payment and shipping updates.

Customer accountCustomer session

GET /api/v1/orders lists, resumes, cancels, and reorders customer purchases.

GET /api/v1/billing/overview shows invoices and subscription state for the authenticated customer.

GET /api/v1/profile updates account profile and notification settings.

GET /api/v1/tickets powers customer support ticket list, detail, and replies.

Forms and contactPublic or customer session

GET /api/v1/forms/{slug} resolves public forms, intake submission state, and form visibility.

POST /api/v1/contact creates a monitored contact event tied to the workspace and customer context when available.

Discovery and engagementPublic session

GET /api/v1/help/sessions stores guided help session state.

GET /api/v1/kb/categories returns help content and feedback data.

GET /api/v1/search powers public site search.

GET /api/v1/reviews exposes public review display data.

POST /api/v1/stories/subscribe supports editorial engagement and comments.

POST /api/v1/{site}/chat/session creates public-site assistant conversations for public or customer sessions.

Route Ownership Rules

Use these rules when debugging a route:

/api/editor/*

Console/editor control plane

First verification: Operator session, selected workspace, membership, role

/api/admin/*

Admin operations

First verification: Operator session, workspace role, provider connection

/api/internal/*

Internal service route

First verification: Caller authorization, workspace ID, service secret where applicable

/api/cron/*

Scheduled maintenance

First verification: Scheduler authorization and idempotency

/api/webhooks/*

Provider or console event receiver

First verification: Signature or shared secret, event family, replay safety

/api/v1/*

Sites customer/public API

First verification: Site resolution, customer/session ownership, request validation

/{site}/*

Public page

First verification: Workspace resolution, publish state, cache/revalidation

Webhook Families

Webhooks keep public surfaces fresh after console changes:

Branding.
Settings.
Domains.
Products.
Bookings.
Pages.
Forms.
Help.
Knowledge content.
Media.
Stripe.
Shipping.

When a public route looks stale, identify the owning console record first, then match that record to the webhook family that should invalidate it. This prevents teams from debugging the wrong layer: a stale product grid, help article, or domain preview is usually a publishing or revalidation problem, not a customer browser problem.

Webhook Route Map

/api/webhooks/branding

Brand or theme save

Public effect: Header, logo, colors, favicon, preview refresh

/api/webhooks/settings

Workspace settings save

Public effect: Public settings, policies, checkout/site behavior

/api/webhooks/domains

Domain or DNS change

Public effect: Host routing and domain diagnostics

/api/webhooks/products

Product/catalog change

Public effect: Shop pages, cart validation, checkout product state

/api/webhooks/bookings

Service, availability, or booking setup change

Public effect: Booking pages and availability state

/api/webhooks/pages

Page publish or unpublish

Public effect: Public page routes and navigation

/api/webhooks/forms

Form publish or schema change

Public effect: Public form load and submissions

/api/webhooks/help

Help configuration change

Public effect: Help center routes

/api/webhooks/kb

Knowledge article change

Public effect: KB article/category pages

/api/webhooks/media

Media upload or deletion

Public effect: Public images, icons, and previews

/api/webhooks/stripe

Stripe account, payment, invoice, checkout, or subscription event

Public effect: Orders, bookings, billing, invoice status, checkout continuation

/api/webhooks/shipping/shippo

Shipping label or tracking provider event

Public effect: Fulfillment state and tracking updates

Webhook handlers should be idempotent, signature-checked, and scoped to the owning workspace before mutating customer-visible state.

Integration Surfaces

Integration

Stripe Connect

Console surface: Payments, Checkout and Tax

Public/customer effect: Checkout, invoices, deposits, refunds, payouts

Integration

GA4

Console surface: Settings > Integrations > Google Analytics

Public/customer effect: Public traffic measurement

Integration

Google Ads

Console surface: Settings > Integrations > Google Ads

Public/customer effect: Conversion tags and booking conversion events

Integration

Google Business Profile

Console surface: Settings > Integrations > Google Business Profile

Public/customer effect: Review/listing sync

Integration

Calendar providers

Console surface: Scheduling > Calendar Sync

Public/customer effect: Availability and event sync

Integration

Domain/email

Console surface: Settings > Domain and Email

Public/customer effect: Public routing and sender identity

Integration

Shipping provider

Console surface: Shipping

Public/customer effect: Rate shopping, labels, tracking

Diagnostics Checklist

When a route fails, collect this packet before changing code:

Workspace slug and public URL.
Exact route and method.
Whether the caller is public, customer, operator, scheduler, provider, or internal service.
Expected owner: console, sites, shared service, provider, or webhook.
Current workspace publish state.
Selected workspace for console requests.
Customer/session identity for portal requests.
Provider event ID or request ID for webhook requests.
Whether the stale result is cache, authorization, validation, provider state, or missing data.

This packet keeps the team from treating a route mismatch as a content bug or treating a cache delay as an auth failure.

Source-Of-Truth Rule

When a workflow crosses console and sites, identify the owner:

Console owns configuration and operator actions.
Sites owns customer rendering and customer actions.
Shared services and database records own cross-app state.
Webhooks and cache tags keep the customer surface current.

Do not duplicate configuration on the public site when a console setting already owns it.