Pulsegate

Appearance

Settings (Dashboard) ​

The dashboard has a dedicated Settings section for configuration and environment-level controls. This section is admin-only: only users connecting with the admin API key can see it or open its routes.

Access ​

  • Sidebar: A "Settings" group appears only for admin users. Marketing users do not see the group.
  • Routes: /settings and /forms-config are protected with AdminRoute; marketing users who open these URLs are redirected to the dashboard.

Settings hub (/settings) ​

The Settings page is a central hub that links to:

  • Forms config — Sites, domains, forms, and integration API keys for lead capture. Same as the former standalone "Forms config" page; now reachable from Settings or directly at /forms-config.
  • Environment & controls — Placeholder for future environment-level options (e.g. bot detection toggles, retention, feature flags).

Forms config (/forms-config) ​

Admin-only. The page has two sections: Sites and Integrations. Integrations is visible only to admin; if the page is ever opened by a non-admin, only Sites is shown.

  • Sites — Create sites, set site keys, add/remove allowed domains, enable/disable.
  • Forms — Create and edit forms (form JSON), embed snippet, enable/disable, delete (under each site).
  • Integrations — Create server-side API keys (for Make.com or other server callers), revoke keys. Admin only (tab and content hidden for marketing).

See Forms config API for the backend APIs.

Sending leads to Make.com ​

The Settings page includes a Sending leads to Make.com card. These options are stored in the AppSettings table (D1) so admins can change them at any time from the dashboard without redeploying:

  • Send leads to Make.com — On/Off. When off, leads are still stored in D1 but never sent to the webhook.
  • Allow sending to Make.com in development — Shown only when the current environment is development. When on, leads from this environment are also sent to the Make.com webhook (for testing). A confirmation modal and warning are shown before enabling. Turn off when done testing.
  • Send whitelist test leads to Make.com — On/Off. When off, leads from IPs whitelisted with usage "test" (and test leads by content) are stored in TestingLeads only.
  • Test lead by content — A list of strings. If name, email, project, or location contains any of these (case-insensitive), the lead is stored in TestingLeads and optionally sent to Make.com with test_lead: yes. Empty list = disabled. Add/remove strings from the Settings page.
  • Bot lead detection (honeypot) — On/Off. When on, submissions that fill the hidden honeypot field are rejected (not sent to Make.com, IP blocked).
  • Store honeypot leads in D1 — On/Off. When on, honeypot (bot) leads are saved to BlockedIPLeads for audit. When off, only the IP is blocked; no lead record is stored in D1.
  • Re-engage duplicate leads — Hours (0 = disabled). When set, a duplicate lead re-submitting after this many hours is sent to Make.com again.
  • Send follow-up leads to Make.com — On/Off. When on, every form submission (including follow-ups from the same person within the re-engage window) is sent to Make.com and appears in Sent to Make.com. When off (default), only the first submission per lead and re-engage after X hours are sent.
  • CRM lead URL template — URL for the "View in CRM" link on lead detail (e.g. https://crm.example.com/lead/). Use for the lead ID. Leave empty to hide the link.
  • Show lead submission charts — On/Off. When on, the Lead submission analytics page loads and displays charts from Analytics Engine. When off, charts are hidden and not queried (the submissions table is still shown).
  • Mask email and phone for marketing — On/Off. When on, users with the marketing API key see masked email and phone in Testing leads, Blocked IP leads, and Lead analytics submissions. When off, marketing sees full contact info.
  • Environment — Read-only; comes from wrangler (e.g. development, production).

Marketing API keys ​

A separate card Marketing API keys lets you generate and manage API keys for marketing users. Each key is auto-generated (e.g. pg_mkt_…) and shown once at creation; you can regenerate a key at any time (the old key stops working). Each key has its own visible pages: when creating or editing a key, you choose which pages that key can access (Dashboard, Lead analytics, Testing leads, Blocked IP leads, Blocked IPs, Whitelisted IPs, Sessions, Replay). Leads, Sent to Make.com, Settings, and Forms config remain admin-only for all keys.

  • Generate new key — Optional name, select visible pages, then Create. Copy the key from the green box; it is not shown again.
  • Edit — Change name and visible pages for an existing key.
  • Regenerate — Invalidates the current key and issues a new one (shown once).
  • Delete — Removes the key; it stops working immediately.

API: GET /analytics/marketing-keys (list), POST /analytics/marketing-keys (create; body: name?, visible_pages?; returns key once), GET /analytics/marketing-keys/:id, PATCH /analytics/marketing-keys/:id (name, visible_pages), POST /analytics/marketing-keys/:id/regenerate (returns new key once), DELETE /analytics/marketing-keys/:id. All admin-only.

Legacy: If you still use ANALYTICS_MARKETING_API_KEY (wrangler), that key uses the global marketing_api_visible_pages from AppSettings (or default). Dashboard no longer exposes that global list in the UI; use Marketing API keys for per-key control.

API (settings): GET /analytics/settings returns current values; PATCH /analytics/settings (admin-only) accepts send_leads_to_make, send_test_leads_to_make, test_lead_contains_strings (array of strings), bot_lead_detection, lead_reengage_hours, store_honeypot_leads, crm_lead_url_template, show_lead_submission_charts, mask_email_phone_for_marketing, and optionally marketing_api_visible_pages (for the env marketing key). If a key is missing in the table, the worker falls back to wrangler env vars.

Banner when sending is off: When send_leads_to_make is false, the dashboard shows a persistent warning banner at the top of every page (for both admin and marketing) so the team is aware that leads are not reaching the CRM. Admins see an "Enable in Settings" link; marketing sees the message only. The layout uses GET /analytics/settings/banner, which returns { send_leads_to_make, show_lead_submission_charts, marketing_visible_pages } and is allowed for all authenticated roles. The lead analytics page uses show_lead_submission_charts to hide charts when off; marketing uses marketing_visible_pages for sidebar and route access control.

Environment-level options and feature flags ​

Behaviour is controlled by Wrangler environment vars and secrets. Current options include:

  • ENVIRONMENT — development vs production (logging, lead forwarding to Make.com)
  • AppSettings table (DB) — send_leads_to_make, send_test_leads_to_make, test_lead_contains_strings (JSON array), bot_lead_detection, lead_reengage_hours, store_honeypot_leads, crm_lead_url_template, show_lead_submission_charts, mask_email_phone_for_marketing, and optionally marketing_api_visible_pages (for the legacy env marketing key) are stored here. MarketingApiKeys table stores dashboard-generated marketing keys, each with its own VisiblePages JSON.
  • SEND_LEADS_TO_MAKE, SEND_TEST_LEADS_TO_MAKE, TEST_LEAD_CONTAINS_STRINGS (optional comma-separated), BOT_LEAD_DETECTION, STORE_HONEYPOT_LEADS, LEAD_REENGAGE_HOURS, CRM_LEAD_URL_TEMPLATE, SHOW_LEAD_SUBMISSION_CHARTS, MASK_EMAIL_PHONE_FOR_MARKETING — wrangler vars used as fallback when not set in AppSettings.
  • LOG_LEVEL, LOG_LEADS, LOG_TRACKING — logging verbosity
  • R2 retention — session/replay data retention (currently 90 days, hardcoded)

Secrets (API keys, CRM callback, etc.) are set via wrangler secret put and are not shown in the dashboard.

See Environment config for the full list and where each is used.