@whop/elements 1.0.0-beta.1 → 1.0.0-beta.3

package/websites.d.cts

@@ -16,12 +16,12 @@ export interface WebsitesOptions {
 	 */
 	windowDays?: number;
 	/**
-	 * List websites built on whop.app from the moment they exist, with zeros until traffic arrives. Turn off to show only domains the pixel reports. @default true
+	 * List websites built on whop.site from the moment they exist, with zeros until traffic arrives. Turn off to show only domains the pixel reports. @default true
 	 * @default true
 	 */
 	includeApps?: boolean;
 	/**
-	 * Websites you have just added that are not live yet — `{ domain, kind }`, where `kind` is `deploy` for a whop.app site waiting on its first deploy or `events` for a site waiting on its first pixel events. They render as waiting rows so a site never looks lost right after setup, and the table polls while any is outstanding. Sites the mounted `pixel-setup` wizard proves live are added for you, kept across a reload, and are NOT your job — this is for the waits the handle cannot see for itself, above all a whop.app site you just created, which no element here reports. Entries you add are yours to remove: a row stops being drawn once its domain reaches the table, but the list itself only changes when you change it, so drop an entry when `websitesLoaded` names its domain and give the rest a timeout of your own.
+	 * Websites you have just added that are not live yet — `{ domain, kind }`, where `kind` is `deploy` for a site on whop.site waiting on its first deploy or `events` for a site waiting on its first pixel events. They render as waiting rows so a site never looks lost right after setup, and the table polls while any is outstanding. Sites the mounted `pixel-setup` wizard proves live are added for you, kept across a reload, and are NOT your job — this is for the waits the handle cannot see for itself, above all a site on whop.site you just created, which no element here reports. Entries you add are yours to remove: a row stops being drawn once its domain reaches the table, but the list itself only changes when you change it, so drop an entry when `websitesLoaded` names its domain and give the rest a timeout of your own.
 	 * @default []
 	 */
 	pendingWebsites?: PendingWebsite[];
@@ -31,12 +31,12 @@ export interface WebsitesOptions {
 	 */
 	showVerify?: boolean;
 	/**
-	 * Add a settings button to whop.app rows. The element only reports the press through `onSettingsRequested` — the editing surface is yours.
+	 * Add a settings button to whop.site rows. The element only reports the press through `onSettingsRequested` — the editing surface is yours.
 	 * @default false
 	 */
 	showSettings?: boolean;
 	/**
-	 * Add an edit button to whop.app rows, styled as the row’s primary action. The element only reports the press through `onEditRequested` — the editing surface is yours.
+	 * Add an edit button to whop.site rows, styled as the row’s primary action. The element only reports the press through `onEditRequested` — the editing surface is yours.
 	 * @default false
 	 */
 	showEdit?: boolean;
@@ -51,7 +51,7 @@ export interface WebsitesOptions {
 	 */
 	verifyStatus?: "idle" | "waiting" | "connected" | "not-detected" | "blocked";
 	/**
-	 * A scoped token for the reads — stats need `stats:read`, and the whop.app website list reads apps (rows degrade to traffic-only if the token can’t). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. `pixel-setup` is the one child this is not projected into — it authenticates its own scans from its own `accessToken` — so mint a single token carrying both sets of scopes and pass that same string to both, rather than one token per element. Omitted, the reads carry the viewer’s own session, which only answers same-origin.
+	 * A scoped token for the reads — stats need `stats:read`, and the whop.site website list reads apps (rows degrade to traffic-only if the token can’t). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. `pixel-setup` is the one child this is not projected into — it authenticates its own scans from its own `accessToken` — so mint a single token carrying both sets of scopes and pass that same string to both, rather than one token per element. Omitted, the reads carry the viewer’s own session, which only answers same-origin.
 	 */
 	accessToken?: string;
 	/**
@@ -124,11 +124,11 @@ export interface WebsitesElementCreateOptions {
 	 */
 	onVerifyRequested?: ((payload: { target: string; url: string; }) => void);
 	/**
-	 * The settings button on a whop.app row was pressed. The element only reports the click — open your own editing surface for the app.
+	 * The settings button on a whop.site row was pressed. The element only reports the click — open your own editing surface for the app.
 	 */
 	onSettingsRequested?: ((payload: { appId: string; route: string; domain: string; }) => void);
 	/**
-	 * The edit button on a whop.app row was pressed. The element only reports the click — open your own editing surface for the app.
+	 * The edit button on a whop.site row was pressed. The element only reports the click — open your own editing surface for the app.
 	 */
 	onEditRequested?: ((payload: { appId: string; route: string; domain: string; }) => void);
 	/**
@@ -156,7 +156,7 @@ export interface PixelSetupElementProps {
 	 */
 	accountId?: string;
 	/**
-	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
+	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). When no `destinationUrl` is passed, the empty URL field also suggests pages from the account’s ads and pixel traffic — those reads need `ad_campaign:basic:read` and `stats:read`, and without them the field is simply bare. Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
 	 */
 	accessToken?: string;
 	/**
@@ -194,6 +194,11 @@ export interface PixelSetupElementProps {
 	 * @default true
 	 */
 	showOptimizePrompt?: boolean;
+	/**
+	 * Lead with the page check instead of the install instructions: the URL field (and its suggestions) sits at the top, the install paths fold under a "Pixel not installed yet?" toggle, and the header reads "Verify your pixel". For an account owner who already has a pixel and is here to find out why nothing is being attributed. Pair it with `showIntro: false`.
+	 * @default false
+	 */
+	verifyFirst?: boolean;
 }
 
 /**
@@ -231,7 +236,7 @@ export interface PixelSetupElementCreateOptions {
 	 */
 	accountId?: string;
 	/**
-	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
+	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). When no `destinationUrl` is passed, the empty URL field also suggests pages from the account’s ads and pixel traffic — those reads need `ad_campaign:basic:read` and `stats:read`, and without them the field is simply bare. Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
 	 */
 	accessToken?: string;
 	/**
@@ -269,6 +274,11 @@ export interface PixelSetupElementCreateOptions {
 	 * @default true
 	 */
 	showOptimizePrompt?: boolean;
+	/**
+	 * Lead with the page check instead of the install instructions: the URL field (and its suggestions) sits at the top, the install paths fold under a "Pixel not installed yet?" toggle, and the header reads "Verify your pixel". For an account owner who already has a pixel and is here to find out why nothing is being attributed. Pair it with `showIntro: false`.
+	 * @default false
+	 */
+	verifyFirst?: boolean;
 	/**
 	 * The account owner set or cleared a redirect URL in the wizard. Persist it and pass it back as `redirectUrl` next time.
 	 */
@@ -281,6 +291,22 @@ export interface PixelSetupElementCreateOptions {
 	 * Done was pressed. Re-check the page yourself — this says the wizard finished, not that your requirements are met.
 	 */
 	onFinished?: ((payload: Record<string, never>) => void);
+	/**
+	 * The account owner named the page to check from inside the wizard — typed by hand, or picked from the suggested pages. Only reachable when no destination was supplied at mount.
+	 */
+	onUrlSubmitted?: ((payload: { url: string; source: "typed" | "suggested"; }) => void);
+	/**
+	 * "Verify live" was pressed. `popupBlocked` means the browser refused the funnel window, so the walk never started.
+	 */
+	onVerifyLaunched?: ((payload: { url: string; popupBlocked: boolean; }) => void);
+	/**
+	 * The funnel page pinged the wizard back — the pixel is loaded there and the walk is live.
+	 */
+	onVerifyConnected?: ((payload: { url: string; }) => void);
+	/**
+	 * The verify-live walk finished. `ok` means no tracking gaps; otherwise `gaps` carries the gap codes the walk found.
+	 */
+	onVerdict?: ((payload: { url: string; ok: boolean; gaps: string[]; eventsCaptured: number; }) => void);
 	/**
 	 * The account owner walked their funnel with "Verify live" and this event fired — proof it is wired where a server-side scan cannot reach.
 	 */
@@ -328,7 +354,7 @@ export interface PixelSetupElementOverlayHandle {
  */
 export interface WebsitesHandle {
 	/**
-	 * An account's websites in one table: every site built on whop.app — listed from the moment it exists, zeros until traffic arrives — merged by hostname with every domain the Whop Pixel reports. Rows for the whop.app sites carry a Whop mark, so the two sources stay apart even when both have traffic. Each row shows a page-view trend, unique visitors, page views, attributed sales, USD revenue, and the last day an event arrived. Expanding a domain loads its most-viewed pages, and each page-view figure opens the breakdown of which events made it up. Set `showVerify` to add a per-row button that asks the page hosting this element to open the site and confirm the pixel is firing; set `showSettings` to add a settings button on whop.app rows that reports the click through `onSettingsRequested`, and `showEdit` to add a primary edit button reporting through `onEditRequested` — your page owns the actual editing.
+	 * An account's websites in one table: every site built on whop.site — listed from the moment it exists, zeros until traffic arrives — merged by hostname with every domain the Whop Pixel reports. Rows for the whop.site ones carry a Whop mark, so the two sources stay apart even when both have traffic. Each row shows a page-view trend, unique visitors, page views, attributed sales, USD revenue, and the last day an event arrived. Expanding a domain loads its most-viewed pages, and each page-view figure opens the breakdown of which events made it up. Set `showVerify` to add a per-row button that asks the page hosting this element to open the site and confirm the pixel is firing; set `showSettings` to add a settings button on whop.site rows that reports the click through `onSettingsRequested`, and `showEdit` to add a primary edit button reporting through `onEditRequested` — your page owns the actual editing.
 	 */
 	create(name: "websites", options?: WebsitesElementCreateOptions): WebsitesElementHandle;
 	/**

package/websites.d.ts

@@ -16,12 +16,12 @@ export interface WebsitesOptions {
 	 */
 	windowDays?: number;
 	/**
-	 * List websites built on whop.app from the moment they exist, with zeros until traffic arrives. Turn off to show only domains the pixel reports. @default true
+	 * List websites built on whop.site from the moment they exist, with zeros until traffic arrives. Turn off to show only domains the pixel reports. @default true
 	 * @default true
 	 */
 	includeApps?: boolean;
 	/**
-	 * Websites you have just added that are not live yet — `{ domain, kind }`, where `kind` is `deploy` for a whop.app site waiting on its first deploy or `events` for a site waiting on its first pixel events. They render as waiting rows so a site never looks lost right after setup, and the table polls while any is outstanding. Sites the mounted `pixel-setup` wizard proves live are added for you, kept across a reload, and are NOT your job — this is for the waits the handle cannot see for itself, above all a whop.app site you just created, which no element here reports. Entries you add are yours to remove: a row stops being drawn once its domain reaches the table, but the list itself only changes when you change it, so drop an entry when `websitesLoaded` names its domain and give the rest a timeout of your own.
+	 * Websites you have just added that are not live yet — `{ domain, kind }`, where `kind` is `deploy` for a site on whop.site waiting on its first deploy or `events` for a site waiting on its first pixel events. They render as waiting rows so a site never looks lost right after setup, and the table polls while any is outstanding. Sites the mounted `pixel-setup` wizard proves live are added for you, kept across a reload, and are NOT your job — this is for the waits the handle cannot see for itself, above all a site on whop.site you just created, which no element here reports. Entries you add are yours to remove: a row stops being drawn once its domain reaches the table, but the list itself only changes when you change it, so drop an entry when `websitesLoaded` names its domain and give the rest a timeout of your own.
 	 * @default []
 	 */
 	pendingWebsites?: PendingWebsite[];
@@ -31,12 +31,12 @@ export interface WebsitesOptions {
 	 */
 	showVerify?: boolean;
 	/**
-	 * Add a settings button to whop.app rows. The element only reports the press through `onSettingsRequested` — the editing surface is yours.
+	 * Add a settings button to whop.site rows. The element only reports the press through `onSettingsRequested` — the editing surface is yours.
 	 * @default false
 	 */
 	showSettings?: boolean;
 	/**
-	 * Add an edit button to whop.app rows, styled as the row’s primary action. The element only reports the press through `onEditRequested` — the editing surface is yours.
+	 * Add an edit button to whop.site rows, styled as the row’s primary action. The element only reports the press through `onEditRequested` — the editing surface is yours.
 	 * @default false
 	 */
 	showEdit?: boolean;
@@ -51,7 +51,7 @@ export interface WebsitesOptions {
 	 */
 	verifyStatus?: "idle" | "waiting" | "connected" | "not-detected" | "blocked";
 	/**
-	 * A scoped token for the reads — stats need `stats:read`, and the whop.app website list reads apps (rows degrade to traffic-only if the token can’t). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. `pixel-setup` is the one child this is not projected into — it authenticates its own scans from its own `accessToken` — so mint a single token carrying both sets of scopes and pass that same string to both, rather than one token per element. Omitted, the reads carry the viewer’s own session, which only answers same-origin.
+	 * A scoped token for the reads — stats need `stats:read`, and the whop.site website list reads apps (rows degrade to traffic-only if the token can’t). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. `pixel-setup` is the one child this is not projected into — it authenticates its own scans from its own `accessToken` — so mint a single token carrying both sets of scopes and pass that same string to both, rather than one token per element. Omitted, the reads carry the viewer’s own session, which only answers same-origin.
 	 */
 	accessToken?: string;
 	/**
@@ -124,11 +124,11 @@ export interface WebsitesElementCreateOptions {
 	 */
 	onVerifyRequested?: ((payload: { target: string; url: string; }) => void);
 	/**
-	 * The settings button on a whop.app row was pressed. The element only reports the click — open your own editing surface for the app.
+	 * The settings button on a whop.site row was pressed. The element only reports the click — open your own editing surface for the app.
 	 */
 	onSettingsRequested?: ((payload: { appId: string; route: string; domain: string; }) => void);
 	/**
-	 * The edit button on a whop.app row was pressed. The element only reports the click — open your own editing surface for the app.
+	 * The edit button on a whop.site row was pressed. The element only reports the click — open your own editing surface for the app.
 	 */
 	onEditRequested?: ((payload: { appId: string; route: string; domain: string; }) => void);
 	/**
@@ -156,7 +156,7 @@ export interface PixelSetupElementProps {
 	 */
 	accountId?: string;
 	/**
-	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
+	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). When no `destinationUrl` is passed, the empty URL field also suggests pages from the account’s ads and pixel traffic — those reads need `ad_campaign:basic:read` and `stats:read`, and without them the field is simply bare. Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
 	 */
 	accessToken?: string;
 	/**
@@ -194,6 +194,11 @@ export interface PixelSetupElementProps {
 	 * @default true
 	 */
 	showOptimizePrompt?: boolean;
+	/**
+	 * Lead with the page check instead of the install instructions: the URL field (and its suggestions) sits at the top, the install paths fold under a "Pixel not installed yet?" toggle, and the header reads "Verify your pixel". For an account owner who already has a pixel and is here to find out why nothing is being attributed. Pair it with `showIntro: false`.
+	 * @default false
+	 */
+	verifyFirst?: boolean;
 }
 
 /**
@@ -231,7 +236,7 @@ export interface PixelSetupElementCreateOptions {
 	 */
 	accountId?: string;
 	/**
-	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
+	 * A scoped token for the scans and the developer invite. The scans need `company:basic:read`; “Invite a developer” additionally needs `authorized_user:create`, and the event presets read the account with `company:balance:read` (without it the wizard still works, on a generic preset list). When no `destinationUrl` is passed, the empty URL field also suggests pages from the account’s ads and pixel traffic — those reads need `ad_campaign:basic:read` and `stats:read`, and without them the field is simply bare. Mint it on your server with `POST /api/v1/access_tokens` and set a fresh one before it expires. Another element that opens this wizard inside itself — the ads `campaign-creator` does — runs these calls on its own token, so add these scopes to that one token rather than minting a second: this element has no way to read a credential you set elsewhere. Omitted, the calls carry the viewer’s own session, which only answers same-origin.
 	 */
 	accessToken?: string;
 	/**
@@ -269,6 +274,11 @@ export interface PixelSetupElementCreateOptions {
 	 * @default true
 	 */
 	showOptimizePrompt?: boolean;
+	/**
+	 * Lead with the page check instead of the install instructions: the URL field (and its suggestions) sits at the top, the install paths fold under a "Pixel not installed yet?" toggle, and the header reads "Verify your pixel". For an account owner who already has a pixel and is here to find out why nothing is being attributed. Pair it with `showIntro: false`.
+	 * @default false
+	 */
+	verifyFirst?: boolean;
 	/**
 	 * The account owner set or cleared a redirect URL in the wizard. Persist it and pass it back as `redirectUrl` next time.
 	 */
@@ -281,6 +291,22 @@ export interface PixelSetupElementCreateOptions {
 	 * Done was pressed. Re-check the page yourself — this says the wizard finished, not that your requirements are met.
 	 */
 	onFinished?: ((payload: Record<string, never>) => void);
+	/**
+	 * The account owner named the page to check from inside the wizard — typed by hand, or picked from the suggested pages. Only reachable when no destination was supplied at mount.
+	 */
+	onUrlSubmitted?: ((payload: { url: string; source: "typed" | "suggested"; }) => void);
+	/**
+	 * "Verify live" was pressed. `popupBlocked` means the browser refused the funnel window, so the walk never started.
+	 */
+	onVerifyLaunched?: ((payload: { url: string; popupBlocked: boolean; }) => void);
+	/**
+	 * The funnel page pinged the wizard back — the pixel is loaded there and the walk is live.
+	 */
+	onVerifyConnected?: ((payload: { url: string; }) => void);
+	/**
+	 * The verify-live walk finished. `ok` means no tracking gaps; otherwise `gaps` carries the gap codes the walk found.
+	 */
+	onVerdict?: ((payload: { url: string; ok: boolean; gaps: string[]; eventsCaptured: number; }) => void);
 	/**
 	 * The account owner walked their funnel with "Verify live" and this event fired — proof it is wired where a server-side scan cannot reach.
 	 */
@@ -328,7 +354,7 @@ export interface PixelSetupElementOverlayHandle {
  */
 export interface WebsitesHandle {
 	/**
-	 * An account's websites in one table: every site built on whop.app — listed from the moment it exists, zeros until traffic arrives — merged by hostname with every domain the Whop Pixel reports. Rows for the whop.app sites carry a Whop mark, so the two sources stay apart even when both have traffic. Each row shows a page-view trend, unique visitors, page views, attributed sales, USD revenue, and the last day an event arrived. Expanding a domain loads its most-viewed pages, and each page-view figure opens the breakdown of which events made it up. Set `showVerify` to add a per-row button that asks the page hosting this element to open the site and confirm the pixel is firing; set `showSettings` to add a settings button on whop.app rows that reports the click through `onSettingsRequested`, and `showEdit` to add a primary edit button reporting through `onEditRequested` — your page owns the actual editing.
+	 * An account's websites in one table: every site built on whop.site — listed from the moment it exists, zeros until traffic arrives — merged by hostname with every domain the Whop Pixel reports. Rows for the whop.site ones carry a Whop mark, so the two sources stay apart even when both have traffic. Each row shows a page-view trend, unique visitors, page views, attributed sales, USD revenue, and the last day an event arrived. Expanding a domain loads its most-viewed pages, and each page-view figure opens the breakdown of which events made it up. Set `showVerify` to add a per-row button that asks the page hosting this element to open the site and confirm the pixel is firing; set `showSettings` to add a settings button on whop.site rows that reports the click through `onSettingsRequested`, and `showEdit` to add a primary edit button reporting through `onEditRequested` — your page owns the actual editing.
 	 */
 	create(name: "websites", options?: WebsitesElementCreateOptions): WebsitesElementHandle;
 	/**