Apex

How Apex uses Apex

Apex runs Apex as a first-class customer. The dashboard every Apex employee uses is the same product every Apex customer uses — same code path, same constraints, same SDK. When we need to measure a new feature, we ship the instrumentation as a customer-facing product first, then consume it ourselves.

This page walks through Apex's own setup as a worked example. If your company looks like Apex — a SaaS product with a partner marketplace — it's also a working template you can follow.

The shape

Apex's Organization is called Apex Inc. It has two workspaces:

WorkspaceVerticalConversion modelSnippet hosts
Platformb2b-saashybridapex.inc, app.apex.inc
Partner Networkmarketplacetwo-sidedpartners.apex.inc

Both workspaces inherit from Apex Inc.'s org-level brand, verified email sending domain, and Stripe Connect account. Each workspace overrides fromLocalPart so outgoing email reads from the right side of the house (team@apex.inc vs marketplace@apex.inc).

How to get there

Any operator at Apex who wants to run Apex-on-Apex clicks through the standard Shape Templates picker and chooses "SaaS with a partner marketplace." No bespoke script, no internal-only flag, no migration. The template:

  1. Stamps both workspaces via the public /api/workspaces endpoint.
  2. Sets Organization.shape = "saas_marketplace" so downstream routing + defaults specialize on the shape tag.
  3. Outputs snippet install instructions for all three hosts.
  4. Links the Platform workspace to the org's primary Stripe; Partner Network either inherits or overrides.

Every other SaaS-plus-marketplace customer ends up in the same place on the same path.

The snippet

The Platform workspace key is apex in production (apex-staging on staging). The snippet is installed in code, not pasted by hand — the root layout renders an <ApexSnippet /> component driven by the NEXT_PUBLIC_APEX_PROJECT_KEY build arg, so every page on app.apex.inc carries it automatically:

<!-- Effectively what <ApexSnippet /> injects on app.apex.inc -->
<script
  src="https://app.apex.inc/api/apex-js?key=apex&domain=registrable"
  async
></script>

?domain=registrable lets the apex_vid cookie follow visitors between apex.inc and app.apex.inc so marketing-to-product attribution chains stay intact.

Crucially, the same snippet runs on both our marketing pages and our authenticated dashboard. Product paths stamp those events surface: "app" so we can slice marketing vs product. The snippet still measures the dashboard and still runs a test pointed at a dashboard URL. It does not hide the shell or intercept product forms. An experiment with no URL stays off those paths.

This is exactly the hybrid we recommend to customers: the browser snippet for behavioral signal, and server-side milestones for source-of-truth outcomes. When an Apex user finishes onboarding, our backend fires onboarding_completed + activated server-side (never from the client), so the activation funnel can't be double-counted or dropped by an ad blocker.

For iOS Safari ATFP compatibility, both workspaces could additionally point a first-party snippet domain (e.g. metrics.apex.inc) at the Apex CDN — that's on the roadmap but not yet enabled here.

Cross-workspace attribution between Platform and Partner Network works via apex.referrer() + the HMAC-signed _apex_from token — a visitor who clicks from the Platform marketing page into Partner Network keeps their UTMs intact.

The identity story

A person who's a customer on Platform and a partner on Partner Network is one human. Apex represents this as a single OrgPerson with two workspace-scoped records:

  • Contact { personId, workspace=Platform, email=chris@apex.inc, lifecycle=customer }
  • AffiliateProfile { personId, workspace=Partner Network, handle=@chris, email=chris@apex.inc }

Both records share personId. Looking up Chris anywhere in the product resolves to both rows, so "Chris is also a partner" is a single-row lookup on the Lead detail page — no join.

The instrumentation story

Apex's dashboard emits its own events via @apex-inc/sdk, the same package customers install. No internal-only shortcut:

import { identify, track, group, feature } from "@apex-inc/sdk";
import { EVENTS } from "@apex-inc/sdk/plg-events";

identify("chris@apex.inc", { plan: "enterprise" });
group("apex-inc", { plan: "enterprise" });

track(EVENTS.ACTIVATED, {
  milestone: "first-experiment-shipped",
  daysToActivation: 1,
});

track(EVENTS.FEATURE_FIRST_USE, {
  featureKey: "shape-templates",
  daysFromSignup: 0,
});

This keeps the SDK honest. If the dashboard can't cleanly emit shape_template_selected through the customer-facing API, then by definition our PLG customers can't emit their own version of it either — and that's a product bug we fix in the SDK, not a private workaround.

The cohort story

Some cohorts only make sense across both workspaces:

  • "People with a Contact in Platform AND an AffiliateProfile on Partner Network" — customers who are also promoters.
  • "People who converted_in_workspace Platform within 30 days of activated_in_workspace Partner Network" — partners who became paying customers.

These live as org-scope Segment records at /dashboard/customers/segments. Because org-scope segments are cross-workspace, one segment definition can target communications from either workspace.

Portfolio view

Apex Inc. is NOT a portfolio viewer — Apex doesn't aggregate metrics across customers (that would be a terrible thing for a data company to do). The Portfolio surface exists for VCs and holdcos; Apex-the-company uses the org dashboard at /dashboard/org instead.

Related

PreviousShape templates