Runtime API

Import runtime functions from @drip-apex/sdk, or call the browser globals after the hosted script has loaded. The globals are compatibility surfaces, but they do not all have the same shape.

Browser global surfaces

The tables below use the npm/window.Drip export names. On window.drip and window.Apex, trackStep/step and getRuntimeTools/getTools are equivalent aliases.

Initialization and state

Tracking

import { flush, track, trackGoal, trackRevenue, trackStep } from "@drip-apex/sdk";
 
track("add_to_cart", { product_id: "example-product", value: 49 });
trackStep("postcode_submitted");
trackGoal("checkout-started");
trackRevenue(119, { orderId: "order-example-1002", currency: "EUR" });
 
await flush();

Consent

Feature flags

import { evaluateFlag, evaluateFlagValue } from "@drip-apex/sdk";
 
const enabled = evaluateFlag("checkout-progress-ui");
const ctaCopy = evaluateFlagValue("checkout-cta-copy", "Continue to checkout");

Diagnostics

import { getDiagnostics } from "@drip-apex/sdk";
 
const diagnostics = getDiagnostics();
console.log({
  initialized: diagnostics.initialized,
  assignments: diagnostics.assignments,
  configSource: diagnostics.configSource,
  runtime: diagnostics.runtime
});

getDiagnostics() is safe for support tooling because it redacts consent and tracking-block details unless SDK debug mode is enabled.

All builds expose customEventsHeld and tracking. The latter reports whether the tracker is started, whether calls are blocked, the reason (consent_required, dnt, screenshot_mode, or not_started), how many events are waiting behind an activation gate, and whether sent events are QA-tagged. This lets QA distinguish a console call from an event that reached the wire.

Related pages

• Feature flags in code
• Consent modes
• InitConfig reference

Decision timing

Read window.drip.getDiagnostics().load.timing (or the imported getDiagnostics().load.timing) in any build, including a forced preview. The same values are page-readable on window.__dripPerf without enabling debug or analytics.

The initial page's decisionAt, decisionLatencyMs, and load.assignmentReadyAt remain unchanged on SPA route changes. timing.lastRouteChange is null until a route evaluation completes, then contains { startedAt, decisionAt, decisionLatencyMs }. Both timestamps are epoch milliseconds; its latency is decisionAt - startedAt for that route evaluation, independent of how long the page has been open. The matching window.__dripPerf fields are last_route_change_started_at, last_route_change_decision_at, and last_route_change_decision_latency_ms (all null before the first route evaluation). A route_change sdk_perf event uses this route-local latency; an init event uses navigation-relative latency.

window.__dripPerf.qa_session_id identifies the QA session (also available as getDiagnostics().qaSessionId). Unreached timestamps are absent, not zero. Timing diagnostics do not change consent or telemetry gates. The sdk_perf event includes decision_latency_ms and forced_experiment_ids when telemetry is allowed.

const timing = window.drip.getDiagnostics().load.timing;
console.table(timing);
console.log(window.__dripPerf.decision_latency_ms);

The runtime remains unchanged. Natural runtime decides within tens of milliseconds of SDK start when config ships inline with the snippet (measured p50 12 ms / p95 54 ms on a large storefront). QA previews, screenshot-mode previews and cookie-forced sessions take the QA config lane and fetch fresh config over the network (measured p50 1.3 s / p95 7 s); they are not representative of launch behaviour. URL-forced sessions without a qa parameter keep the inline or cached config, so these measurements do not describe them. No config preload or anti-flicker hold is planned.