> ## Documentation Index > Fetch the complete documentation index at: https://docs.openlayer.com/llms.txt > Use this file to discover all available pages before exploring further. # Netskope > Discover GenAI usage from your Netskope tenant's application events The Netskope connector reads **application events** from your Netskope tenant through Netskope's REST API v2 and keeps only the activity for GenAI services. Each AI service then appears as **Seen by Netskope** in your [Shadow AI discovery](https://docs.openlayer.com/integrations/shadow-ai-discovery.md) findings, with usage and blocked attempts counted separately. The gateway reaches Netskope over outbound HTTPS. Nothing needs to reach the gateway. ## What the gateway reads * **Application events only**, from `GET /api/v2/events/dataexport/events/application`. * **Not** page, network, or transaction events, and **not** alerts. Findings never add up numbers in different units, so Netskope contributes exactly one stream. Reading alerts as well would count every block twice. * **No content.** No prompts, responses, or files are read. ## Prerequisites * Shadow AI discovery turned on for your deployment. See [Shadow AI discovery](https://docs.openlayer.com/integrations/shadow-ai-discovery.md). * A Netskope admin who can create a service account and a role for it. * Someone who can set an environment variable on the gateway host. If Openlayer runs your gateway, that's us. ## Set up **1. Create a service account and API token in Netskope** In the Netskope console, go to **Settings → Administration → Administrators & Roles → Administrators** and click **Service Account**. * Assign it a role that can read application events through REST API v2. The token only needs **read** access to `/api/v2/events/dataexport/events/application`. * Generate a REST API token, and set its expiration in days. Copy the token. **2. Allow the gateway's IP addresses** If your tenant restricts API access with an IP allowlist (**Settings → Administration → IP Allowlist**), add the gateway's egress IP addresses to it. If Openlayer runs your gateway, ask us for them. Skip this step if your tenant has no allowlist. **3. Put the token on the gateway host** Set the token in an environment variable on the gateway host, such as `NETSKOPE_API_TOKEN`, and restart the gateway. If Openlayer runs your gateway, coordinate with us to set it. The admin portal stores only the variable's name, never the token. **4. Connect Netskope** In the admin portal, go to **Shadow AI → Discovery**, click **Connect**, and choose **Netskope**. Fill in: * **Tenant hostname**: your tenant's host, such as `acme.goskope.com`. A pasted URL is reduced to its host. * **API token env var**: the variable from the previous step. It defaults to `NETSKOPE_API_TOKEN`. * **Backfill days**: how far back the first sync reads, from 1 to 30. It defaults to 7. Click **Connect**. The gateway checks the tenant and token with one call on a throwaway iterator index, so its real read position is never touched by the check. If the token is rejected, the error says so. The first sync starts right away. Findings appear as it reads, and a long backfill catches up over several syncs. ## How the gateway reads * **It uses its own read position.** Netskope's export API tracks each consumer's position by an *iterator index*. The gateway uses its own, `olga_discovery_`, shown on the connector card as **Iterator index**. **Never reuse it** in a SIEM, the Splunk add-on, or Cloud Exchange: Netskope splits the records between consumers that share an index, so each would miss events. * **It syncs every 5 minutes.** Click **Sync now** on the card to start one immediately. Only one sync runs at a time. * **The first sync reads back the backfill.** Later syncs continue from where the last one stopped. * **It respects Netskope's rate limit.** The export API allows 4 requests per second per endpoint, shared with your other consumers. The gateway waits as long as Netskope asks between pages, and backs off when it's told to. * **It recovers from interruptions without double-counting.** If a sync is cut off mid-page, the next sync asks Netskope to resend that page, and events already counted aren't counted again. If a page still can't be stored or read again after 3 attempts, the gateway moves on and the card shows a warning. ## Which events count as GenAI An application event is kept if one of these matches, checked in order: 1. The host of its `url` (or its `domain`, when the URL has none) is a domain in the catalog of AI services. 2. Its `app` is the name of a catalog service, matched **exactly**. Netskope names every SaaS app, so a loose match would turn "Notion" into "Notion AI". 3. Its `appcategory` is an AI category, such as "Generative AI". The app appears under Netskope's name for it, with **Unknown** risk until it's added to the catalog. Everything else is counted by reason on the connector card and discarded, never stored. Netskope's export API has no server-side filter, so every application event in your tenant passes through the gateway to be filtered. ## Usage and blocked attempts Netskope's `action` field decides how an event counts: | `action` | Counts as | | - | - | | `allow`, `bypass`, `alert`, or empty | Usage. The activity happened. | | `block` | A blocked attempt. It never counts as usage. | | Anything else, such as `useralert` | Not stored. Counted as an unrecognized action. | ## Fields used | Field | Use | | - | - | | `_id` | Netskope's record ID, so a resent event is never counted twice | | `timestamp` | Event time | | `app` | App name, matched exactly against the catalog | | `appcategory` | AI-category fallback for apps not in the catalog | | `url`, `domain` | Host, matched against catalog domains | | `user` | Who used it, only when it's an email address | | `action` | Usage or blocked attempt (see above) | | `activity`, `access_method` | Not used for counting. Shown in **Values seen** on the card | The gateway stores per-minute counts by service, host, user, and outcome for 30 days, plus the IDs of events it has already counted. It never stores raw events. Disconnecting Netskope deletes what it stored. ## How findings appear * Findings list **Seen by Netskope**, counted in **app events**. A count is the number of activities Netskope recorded, not prompts or sessions: one event may carry many prompts, or none. * Blocked attempts are reported separately and never count as usage. * Per-user figures come from the `user` email. ## The connector card Open **Connect** on the Discovery page to see the Netskope card. It shows: * How often it syncs, and **Sync now**. * Totals: GenAI app events stored, duplicates, app events not stored (not GenAI or an unrecognized action), and rejected events. * The newest event seen, and how far behind now it is. * The **Iterator index**. * Warnings, if a page failed to store or the gateway gave up re-reading one. * What the last sync read and kept. * **Values seen**: the most common `action`, `activity`, `access_method`, and `appcategory` values on your GenAI app events. ## Limitations * Only traffic that Netskope steers and inspects produces application events. * Events from apps connected through Netskope's CASB API are included and counted too. * There are no device counts. Netskope's `device` field is a device type, not an ID. * No prompt or file content is available. ## Troubleshooting > **Connecting fails with HTTP 401 or 403** > > Netskope rejected the token. Check that the service account's role can read > `/api/v2/events/dataexport/events/application` and that the token hasn't expired. If your tenant > uses an IP allowlist, check that it includes the gateway's egress IP addresses. > > After you replace the token, update the environment variable on the gateway host and restart > the gateway. > **The card reports HTTP 409** > > Something else is reading with the gateway's iterator index. Remove the index from whatever else > uses it. Only the gateway should read with `olga_discovery_`. > **The newest event seen stays far behind now** > > A long backfill takes several syncs to catch up, so give it time after connecting. If it keeps > falling behind, your tenant may produce more application events than the gateway reads per > sync. [Reach out to us](mailto:support@openlayer.com). > **Many events are counted as an unrecognized action** > > Your tenant sends `action` values the gateway doesn't map. They're listed under **Values seen** > on the card. [Send them to us](mailto:support@openlayer.com) so they can be mapped. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.