# Norton LifeLock

- Tool: Bubble
- Difficulty: Advanced
- Time required: 2–4 hours (after receiving partner API credentials from Gen Digital)
- Last updated: July 2026

## TL;DR

Connect Bubble to Norton LifeLock through the Bubble API Connector targeting Norton's enterprise partner API — available only after completing Gen Digital's formal partnership program. The API key lives in a Private header so enterprise credentials never leave Bubble's servers. Teams without API access can use a CSV-export bridge from business.norton.com to load member status data into Bubble's database on a regular refresh cycle.

## Bubble + Norton LifeLock: an employee-benefits portal built on enterprise identity protection

Norton LifeLock occupies a unique position in this integration category: it is the most access-restricted DevOps and security tool you can connect to Bubble. There is no sign-up page, no free API trial, and no developer sandbox. Access to the partner API is gated behind Gen Digital's formal enterprise onboarding process — a business relationship, not a technical credential you can self-provision. This makes the integration fundamentally different from other security tools like Trend Micro Cloud One (self-serve API key) or even McAfee/Trellix ePO (enterprise license, but a REST API you can access once licensed). Understanding this upfront matters because it changes how you plan the project: budget time for the partnership application, expect that your account manager will provide a private base URL rather than a documented public endpoint, and scope the Bubble work after credentials arrive.

Once you have partner credentials, the Bubble side of the integration is straightforward and well-suited to Bubble's security model. The API Connector stores the Bearer token in a Private header — Bubble's servers include it in every outbound request, but it never reaches a user's browser. A Scheduled Backend Workflow polls the identity alert endpoint on a regular interval (typically every 60 minutes) and stores results in a Bubble IdentityAlert data type. A Bubble dashboard page then displays enrolled members, protection status, and alert severity counts from Bubble's own database — fast to load, no per-user API calls.

For teams that cannot wait for the enterprise partnership (or whose seat counts make API polling impractical), the CSV-export bridge is a proven alternative. business.norton.com's Member Status Report exports a CSV of enrolled employees with their protection status, enrollment date, and coverage tier. A recurring Bubble import flow reads this CSV and upserts records into the same IdentityAlert data type, using employee_email as the unique identifier. Displaying a 'Last updated:' timestamp prominently in the Bubble dashboard is essential so users understand the data is periodic, not live.

## Before you start

- A completed Gen Digital enterprise partner agreement — contact partner.norton.com to begin the process; the API is not available before this step regardless of any technical setup
- Norton enterprise API credentials: a Bearer token and a private endpoint base URL provided by your Norton account manager after onboarding
- A Bubble app on the Starter plan or above (Backend Workflows, required for scheduled polling and secure write operations, are not available on the free plan)
- The free API Connector plugin by Bubble installed in your app (Plugins → Add plugins → search 'API Connector')
- A Bubble data type ready for Norton identity alert records with Admin-only privacy rules (to be set up in Data → Privacy before any live data enters the database)
- For the CSV bridge alternative: admin access to business.norton.com to download the Member Status Report

## Step-by-step guide

### 1. Step 1 — Contact Gen Digital and obtain enterprise partner API credentials

Before any Bubble configuration work begins, you must complete Gen Digital's enterprise partner onboarding. Navigate to partner.norton.com and submit an inquiry, or contact your existing Norton LifeLock account representative and request API access for a Bubble application. The process includes a business review, an agreement signature, and a technical onboarding session where Gen Digital provides: (1) a private API endpoint base URL (commonly following the pattern https://api.norton.com/enterprise/v1/ — your exact URL is confirmed by your account manager), (2) a Bearer token for authentication, and (3) documentation specific to your agreement tier covering available endpoints and rate limits. Save the Bearer token immediately in a password manager — it is shown only once. Note that the enterprise contract specifies the IP ranges from which calls may originate; ask your Norton account manager whether IP allowlisting applies to your agreement, because Bubble Cloud uses dynamic IPs that cannot be statically allowlisted. If IP allowlisting is required, inquire about Bubble's Dedicated Cluster product, which provides dedicated infrastructure. Do not attempt to configure the Bubble API Connector until credentials are in hand — there is no public test endpoint to validate against.

```
// Norton LifeLock Enterprise Partner API
// Credential checklist from Gen Digital onboarding:

// 1. Bearer token (displayed once — store immediately)
//    Format: a long alphanumeric string
//    Used as: Authorization: Bearer {token}

// 2. Private base URL from account manager
//    Example pattern (verify from your partner docs):
//    https://api.norton.com/enterprise/v1/

// 3. Rate limits
//    Specified in your enterprise agreement (not publicly documented)
//    Ask your account manager for the per-minute/hour limits

// 4. IP allowlisting
//    Ask: does the agreement require IP allowlisting?
//    Bubble Cloud = dynamic IPs (not allowlistable without Dedicated Cluster)
```

**Expected result:** You have received a Bearer token and a private endpoint base URL from Gen Digital. You have confirmed whether IP allowlisting applies and documented your per-period rate limits. The token is saved securely in a password manager.

### 2. Step 2 — Configure the Bubble API Connector with Private credentials

Open your Bubble app editor and click 'Plugins' in the left sidebar. If the API Connector plugin does not appear in your installed plugins list, click 'Add plugins,' search for 'API Connector,' and install it (it is free and published by Bubble). Return to the Plugins tab and click 'API Connector.' Click 'Add another API.' Name this group 'Norton LifeLock.' In the 'Root URL' field, enter the private base URL from your Norton account manager — for example, https://api.norton.com/enterprise/v1. Under 'Shared headers across all calls,' click 'Add a shared header.' Set the key to 'Authorization' and the value to 'Bearer YOUR_TOKEN' (replacing YOUR_TOKEN with the actual Bearer token from Gen Digital). Tick the 'Private' checkbox next to this header — this is mandatory. The Private flag means Bubble's servers insert this credential into outbound requests but never expose it in API responses sent to user browsers. If your Norton account manager specified any additional required headers (such as an X-Partner-ID or X-Client-ID), add those as shared headers now, marking them Private as well. Do not add any Norton data call definitions yet — first create the Bubble data type and privacy rules in the next step.

```
// Bubble API Connector — Norton LifeLock group configuration
{
  "api_group_name": "Norton LifeLock",
  "root_url": "https://api.norton.com/enterprise/v1",
  "shared_headers": [
    {
      "key": "Authorization",
      "value": "Bearer <private>",
      "private": true
    },
    {
      "key": "Content-Type",
      "value": "application/json"
    }
  ]
  // Add any additional partner-specific headers from your Norton docs here
}
```

**Expected result:** The Norton LifeLock API group appears in your Bubble API Connector with the correct root URL and an Authorization header marked Private. No API calls are defined yet and no Initialize call has been run.

### 3. Step 3 — Create the IdentityAlert data type with Admin-only privacy rules

Before any Norton data enters Bubble's database, you must configure the data type and its privacy rules. Click 'Data' in the left sidebar, then 'Data types.' Click 'Add a new type' and name it 'IdentityAlert.' Add the following fields: 'member_email' (text), 'member_name' (text), 'protection_status' (text, for values like Active, Pending, Cancelled), 'alert_severity' (text, for values like High, Medium, Low, None), 'alert_type' (text), 'coverage_tier' (text), 'last_checked' (date). Now click 'Privacy' in the Data tab. Find the IdentityAlert type in the list and click to configure rules. Delete or edit the default 'Everyone' rule so that no unauthenticated users can access any fields. Add a rule: Condition = 'Current User has role Admin' (or however your app defines admin users) → check 'View all fields' and 'Modify all fields.' If individual employees should see their own records, add a second rule: Condition = 'Current User's email = This IdentityAlert's member_email' → check only 'View all fields.' Do not allow public access under any condition — identity protection data is regulated PII. Also go to Settings → API → and ensure 'Enable Data API' is OFF unless you have explicitly locked down all API endpoints; an enabled Data API without strict constraints exposes data to anyone with the URL.

```
// Bubble Data Tab — IdentityAlert data type structure
// Data → Data types → IdentityAlert

// Fields to create:
// member_email       — text       (unique key for deduplication)
// member_name        — text
// protection_status  — text       (Active | Pending | Cancelled)
// alert_severity     — text       (High | Medium | Low | None)
// alert_type         — text       (IdentityTheft | DarkWeb | Credit)
// coverage_tier      — text       (Standard | Plus | Ultimate)
// last_checked       — date

// Data → Privacy → IdentityAlert rules:
// Rule 1: Current User has role Admin → View all fields, Modify all fields
// Rule 2: Current User's email = This IdentityAlert's member_email → View all fields
// Default: no access (no Everyone rule)
```

**Expected result:** The IdentityAlert data type exists with all required fields. Privacy rules prevent unauthenticated access. Admin users can view and modify all records; enrolled employees can view only their own records. The Bubble Data API is confirmed disabled.

### 4. Step 4 — Add the 'Get Identity Alerts' API call and initialize it

Return to Plugins → API Connector → Norton LifeLock group. Click 'Add call.' Name this call 'Get Identity Alerts.' Set the method to GET. In the endpoint field (relative to the root URL), enter the identity alert endpoint path from your Norton partner documentation — a common pattern is /members/alerts (your exact path is confirmed by your account manager). Add a URL parameter 'limit' with example value '100' to control page size, and a 'page' parameter for pagination if your partner docs describe a paginated response. Set 'Use as' to 'Data.' Now click 'Initialize call.' Bubble makes a real GET request to the Norton API. For the Initialize call to succeed, your Norton environment must have at least one enrolled member with data — if the response is an empty array, Bubble cannot detect field names. If initialization succeeds, Bubble shows the detected response fields. Map the fields to your IdentityAlert data type. If initialization returns an error: a 401 means the Bearer token is wrong or expired; a 403 means the token does not have permission for this endpoint (verify with your account manager); a 404 means the endpoint path differs from your partner docs. Click 'Save' after successful initialization.

```
// Bubble API Connector — Norton LifeLock 'Get Identity Alerts' call
{
  "call_name": "Get Identity Alerts",
  "method": "GET",
  "endpoint": "/members/alerts",
  "headers": [
    // Inherited from group: Authorization: Bearer <private>
  ],
  "parameters": [
    { "key": "limit", "value": "100" },
    { "key": "page",  "value": "1" }
  ],
  "use_as": "Data"
}

// Expected response structure (verify from partner docs):
// {
//   "members": [
//     {
//       "email": "employee@company.com",
//       "name": "Jane Smith",
//       "protection_status": "Active",
//       "coverage_tier": "Ultimate",
//       "alerts": [
//         {
//           "type": "DarkWeb",
//           "severity": "High",
//           "detected_at": "2026-07-01T08:00:00Z"
//         }
//       ]
//     }
//   ]
// }
```

**Expected result:** The 'Get Identity Alerts' call is initialized with a green checkmark. Bubble shows detected fields matching the Norton API response structure. The call is set to 'Use as: Data.' No errors appear in initialization.

### 5. Step 5 — Create a Scheduled Backend Workflow to poll and store Norton data

Navigate to the Backend Workflows section in Bubble's editor (left sidebar → Backend Workflows, available on Starter plan and above). Click 'Add a new API Workflow' or use the dedicated recurring workflow setup. Name this workflow 'Sync Norton Identity Alerts.' Configure it as a Scheduled API Workflow. Add these steps inside the workflow: Step 1 — Call the 'Get Identity Alerts' API Connector call. Step 2 — For each item in the result list (use 'List of results from step 1'), run a sub-workflow: search for an existing IdentityAlert record where member_email = current item's email. If found, update it with the latest protection_status, alert_severity, and last_checked timestamp. If not found, create a new IdentityAlert record. To schedule the recurring run: in the Bubble editor, go to Settings → Scheduled workflows, or trigger it from an app initialization workflow using 'Schedule API Workflow' action with a recurring interval of 3600 seconds (60 minutes). Note: Scheduled Backend Workflows consume Workload Units on every run — if Norton's API returns 500 members and each triggers a database lookup and update, this is roughly 1,000 WU per cycle. Consider your Bubble plan's WU capacity when setting the polling interval for large member counts.

```
// Bubble Backend Workflow: 'Sync Norton Identity Alerts'
// Settings → API → "This app exposes a Workflow API" must be ON
// Backend Workflows section → Add new API Workflow

// Step 1: Call Norton API
// Action: Call an API connector call
//   Call: Norton LifeLock > Get Identity Alerts
//   limit = 100, page = 1

// Step 2: For each member in result
// Action: Schedule API Workflow on a list
//   List: Result of step 1's members
//   Workflow: Upsert IdentityAlert record

// Sub-workflow: Upsert IdentityAlert
// Step 2a: Search for IdentityAlert where member_email = this item's email
// Step 2b: If found — Make changes to: protection_status, alert_severity,
//          alert_type, last_checked = Current date/time
// Step 2b: If not found — Create new IdentityAlert with all fields

// Scheduling (action in an app-start or initialization workflow):
// Action: Schedule API Workflow
//   Workflow to schedule: Sync Norton Identity Alerts
//   Scheduled time: Current date/time + 3600 seconds
//   Recurs: Yes, every 3600 seconds
```

**Expected result:** The 'Sync Norton Identity Alerts' Backend Workflow exists and is scheduled to run every 60 minutes. On the first manual run, IdentityAlert records are created in the Bubble database for each enrolled Norton member. The last_checked field is populated with the current timestamp.

### 6. Step 6 — Build the Norton dashboard page (or implement the CSV bridge alternative)

**Dashboard path:** Create a Bubble page named 'norton-dashboard' (or 'security'). Add a Repeating Group element. Set the data type to 'IdentityAlert' and the data source to 'Do a search for IdentityAlert with constraint: Current User has role Admin' (or filtered by current user's email for the employee self-service variant). Inside the repeating group, add text elements bound to Current Cell's IdentityAlert's member_name, member_email, protection_status, and alert_severity. Style protection_status with conditional colors (Active = green, Pending = yellow, Cancelled = red). Add a summary card above the repeating group showing counts: 'Active members: count of IdentityAlert where protection_status = Active' and 'High severity alerts: count of IdentityAlert where alert_severity = High.' Add a 'Last synced:' text element bound to your APIHealth record's last_successful_norton_sync date. **CSV bridge alternative (for teams without API access):** Add a FileUploader element to an admin page. Add a Button 'Import Norton CSV.' On click, trigger a Backend Workflow that reads the uploaded CSV file (Bubble supports CSV parsing via the 'Process a list of CSV rows' action). Map columns: member_email → IdentityAlert's member_email, protection_status → protection_status, coverage_tier → coverage_tier. Upsert records using member_email as the deduplication key. Set last_checked to Current date/time and display a success message with import count. If you need help wiring the two-path Norton integration into a production Bubble app, RapidDev's team has built dozens of security and employee-benefits Bubble apps — book a free scoping call at rapidevelopers.com/contact.

```
// Bubble page: norton-dashboard
// Repeating Group settings:
// Type of content: IdentityAlert
// Data source: Do a search for IdentityAlert
//   Constraint: [Admin check or Current User email match]
//   Sort by: alert_severity (descending), then member_name (ascending)

// Summary card above repeating group:
// Active members count: Search for IdentityAlert:count where protection_status = "Active"
// High alerts count:    Search for IdentityAlert:count where alert_severity = "High"

// Last synced text:
// Bound to: Search for APIHealth:first item's last_successful_norton_sync
// Format: "Last synced: [date formatted as MMM D, YYYY h:mm A]"

// CSV bridge workflow trigger:
// Button click → Schedule API Workflow: Process Norton CSV
//   Parameter: FileUploader's value (CSV file)
// Backend Workflow steps:
//   1. Process a list of CSV rows from Parameter
//   2. For each row: search IdentityAlert where member_email = row's email
//      If found: update fields; If not found: create new record
//   3. Create APIHealth record: last_successful_norton_sync = Current date/time
//   4. Return result to page with row count
```

**Expected result:** The Norton dashboard displays enrolled members with their protection status color-coded, alert severity counts, and a 'Last synced' timestamp. The CSV bridge (if used) imports member records on demand, with duplicate member_email entries updating existing records rather than creating duplicates.

## Best practices

- Always mark the Norton Bearer token header as 'Private' in the API Connector — identity protection data API keys are high-value targets, and the Private flag ensures the credential stays on Bubble's servers and never reaches user browsers.
- Configure IdentityAlert privacy rules before any Norton data enters Bubble's database — privacy rules cannot retroactively protect data that was already read through the Data API without rules in place.
- Store a 'last_successful_sync' timestamp in an APIHealth data type and display it prominently in the Norton dashboard — users need to understand that displayed data is periodically refreshed, not live real-time.
- Use employee_email as the unique deduplication key in all import flows (both live API sync and CSV bridge) — relying on Norton-generated member IDs creates orphan records if IDs change after member re-enrollment.
- Add Workload Unit awareness to the sync interval — polling Norton's API for 1,000 members every 15 minutes will generate significant WU consumption; 60-minute intervals are sufficient for identity alert monitoring and dramatically reduce WU costs.
- Ask your Norton account manager for the exact API rate limits specified in your enterprise agreement before setting the polling interval — exceeding partner API rate limits may result in temporary account suspension.
- Keep a secure backup of the Norton Bearer token in a password manager or secrets vault separate from Bubble — the token is shown only once at generation time, and losing it requires re-contacting Norton enterprise support for a new credential.
- For the CSV bridge path, automate a reminder workflow in Bubble (a weekly email to the HR admin) prompting them to download and upload the fresh Member Status Report — manual refresh patterns fail silently when the human step is skipped.

## Use cases

### HR employee benefits dashboard showing Norton enrollment and alert status

An HR team manages Norton LifeLock seats for all employees through a Bubble internal app. The dashboard shows each employee's enrollment status, their current protection tier, and whether any identity alerts are open. A Scheduled Backend Workflow polls the Norton partner API every 60 minutes and updates Bubble's database. HR managers see real-time-ish data without needing Norton admin credentials.

Prompt example:

```
Every 60 minutes, call Norton Partner API 'Get Identity Alerts' for all enrolled members, create or update Bubble IdentityAlert records with fields: member_email, alert_severity, alert_type, protection_status, last_checked timestamp
```

### Employee self-service portal showing personal Norton protection status

A Bubble app lets employees view their own Norton LifeLock protection status, enrolled email addresses, and any open identity alerts — all sourced from the Norton partner API, stored in Bubble with row-level privacy rules so each employee sees only their own records.

Prompt example:

```
When page loads and Current User is logged in, search IdentityAlert records where member_email = Current User's email, display protection_status, alert_severity list, and last_checked timestamp
```

### CSV-bridge periodic member status import for large seat counts

A company with 5,000+ Norton seats uses the CSV export from business.norton.com rather than API polling. An admin uploads the Member Status Report CSV to a Bubble page once a week. A Backend Workflow parses the upload and upserts IdentityAlert records, with employee_email as the deduplication key. The dashboard shows the last import timestamp so users know data freshness.

Prompt example:

```
When CSV file is uploaded, run Backend Workflow: for each row in uploaded CSV, find existing IdentityAlert record where member_email = row email — if found update protection_status and coverage_tier, if not found create new IdentityAlert record; set last_import_at = Current date/time
```

## Troubleshooting

### Initialize call returns 'There was an issue setting up your call' with a 401 error

Cause: The Bearer token in the Authorization header is invalid, expired, or was formatted incorrectly. The most common mistake is copying extra whitespace around the token or omitting the 'Bearer ' prefix before the token string.

Solution: Open API Connector → Norton LifeLock group → shared headers. Verify the Authorization header value is exactly 'Bearer YOUR_TOKEN_VALUE' with a single space between 'Bearer' and the token, and no trailing spaces. Test the same token directly in Postman against the endpoint URL to confirm it works outside Bubble. If the token has expired (Norton may issue time-limited partner tokens), contact your Norton account manager for a refreshed credential.

### API calls succeed during testing but fail in production with connection errors or 403 responses

Cause: Norton's enterprise API enforces IP allowlisting in some partner agreements. Bubble Cloud uses dynamic, shared IP addresses that cannot be statically allowlisted. The API may have accepted test calls coincidentally but blocks production traffic as allowlist rules take effect.

Solution: Contact your Norton account manager and ask explicitly whether IP allowlisting is configured for your agreement. If yes, ask about Bubble's Dedicated Cluster option, which provides dedicated infrastructure with stable IPs. Alternatively, negotiate with Norton to allowlist Bubble's IP range or configure the integration through a proxy with a static IP that is allowlisted.

### Bubble Scheduled Backend Workflow does not run or stops running after a plan downgrade

Cause: Backend Workflows and Scheduled Workflows are only available on Bubble Starter plan and above. If the app is on the Free plan, or if the plan was downgraded, scheduled workflows are disabled silently — no error, they simply stop executing.

Solution: Go to Settings → Plan in the Bubble editor and confirm the app is on Starter or above. If recently downgraded, upgrade the plan to restore Backend Workflow access. Add a health-check by creating a simple 'Last sync status' field on your APIHealth record and checking it manually if Norton data seems stale — a missing last_checked update indicates the workflow stopped.

### CSV import creates duplicate IdentityAlert records for the same employee email

Cause: The Backend Workflow that processes the CSV is not searching for existing records before creating new ones — it runs a 'Create new IdentityAlert' action unconditionally, resulting in one new record per import row on every upload.

Solution: In the Backend Workflow, the step order must be: (1) Search for IdentityAlert where member_email = current CSV row's email value. (2a) Only if the search returns results, run 'Make changes to Thing' on the first result to update fields. (2b) Only if the search returns no results (count = 0), run 'Create new Thing.' Use Bubble's 'Only when' condition on each Create/Modify action to enforce the upsert logic.

### Norton dashboard shows IdentityAlert records to all logged-in users, including non-admins who should not see other employees' records

Cause: Privacy rules on the IdentityAlert data type were not configured, or the 'Everyone' default rule was left in place, allowing any authenticated user to query all records via Bubble's Data API or repeating group searches.

Solution: Go to Data → Privacy → IdentityAlert. Remove the 'Everyone' rule. Add a rule for admin users (view and modify all) and a rule for individual employees (view only where member_email matches Current User's email). Test by logging in as a non-admin user and verifying the repeating group shows only that user's own record.

## Frequently asked questions

### Can I get a Norton LifeLock API key to test without completing the enterprise partner program?

No. Norton LifeLock has no public developer API, no sandbox environment, and no free trial API key. The only path to API access is completing Gen Digital's formal enterprise partner onboarding process at partner.norton.com. Until partner credentials arrive, use the CSV-export bridge from business.norton.com as a functional alternative that supports the same Bubble dashboard.

### Does the Norton integration require a paid Bubble plan?

Yes, for the live API integration path. Scheduled Backend Workflows (which poll Norton's API every 60 minutes) require the Bubble Starter plan or above. The free Bubble plan does not support Backend Workflows at all, which means no scheduled polling and no server-side write operations. The CSV bridge alternative can work on the free plan if you trigger the import manually via a button click rather than a scheduled workflow.

### Can Norton LifeLock send webhooks to Bubble when an identity alert fires?

Native webhook delivery from Norton to Bubble is not available without a formal SIEM integration agreement — standard enterprise partner access does not include inbound webhook push. The standard pattern is Bubble polling the Norton API on a scheduled interval. If real-time alerting is a hard requirement, discuss SIEM integration options with your Norton account manager as a separate advanced scope item.

### What happens if I lose the Norton Partner Portal API token?

The Bearer token is shown only once at generation time in the Norton Partner Portal. If the token is lost, you must contact Norton enterprise support and request a new credential — there is no 'reveal token' option. This is why storing the token immediately in a password manager (not just in the Bubble API Connector field) is critical. If the token is compromised, contact Norton support to revoke it and issue a replacement.

### How can Bubble handle Norton's dynamic IP allowlisting conflict?

Bubble Cloud runs on shared infrastructure with dynamic IP addresses that change over time — you cannot provide Norton with a static IP for allowlisting. If your Norton enterprise agreement requires IP allowlisting, your options are: (1) inquire about Bubble's Dedicated Cluster product for dedicated infrastructure IPs, (2) use an intermediate proxy with a static IP that is allowlisted and forwards calls to Norton, or (3) negotiate with Norton to permit the range of IPs Bubble Cloud uses (contact Bubble support for their current IP ranges).

### Is it safe to store Norton member PII (names, emails, alert types) in Bubble's database?

Yes, with proper configuration. Bubble's database is hosted on AWS with encryption at rest. The critical security steps for PII like Norton member data are: (1) configure strict privacy rules on the IdentityAlert data type so only admins and the individual member can access their own record, (2) disable Bubble's Data API for this app unless you have reviewed every data type's public access settings, and (3) avoid logging PII in Bubble's Workflow Logs beyond what is necessary for debugging.

---

Source: https://www.rapidevelopers.com/bubble-integrations/norton-lifelock
© RapidDev — https://www.rapidevelopers.com/bubble-integrations/norton-lifelock