> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Linking GitGuardian as a source

Canonical URL: https://posthog.com/docs/data-pipelines/sources/gitguardian

> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://us.posthog.com` or `https://app.posthog.com` (app host for links).

## On this page

- [Prerequisites](#prerequisites)
- [Adding a data source](#adding-a-data-source)
- [Available tables](#available-tables)
- [Sync modes](#sync-modes)
- [Configuration](#configuration)
- [Supported tables](#supported-tables)
- [Troubleshooting](#troubleshooting)

**Beta release**

This source is currently in **beta**. It works end to end, but you may still hit rough edges. [Let us know](https://us.posthog.com/#panel=support%3Asupport%3Adata_warehouse%3A%3Atrue) if you do.

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_9608fcca70)

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_dark_a92b0e022d)

Let AI connect your sources for you

Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.

`npx @posthog/wizard warehouse`

![PostHog Wizard hedgehog](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)

![](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)Let AI connect your sources for you

The [GitGuardian](https://www.gitguardian.com) connector syncs your secret incidents, their occurrences, monitored sources, honeytokens, members, and teams into PostHog, so you can track exposure volume, remediation time, and per-repository risk alongside your other engineering data.

## Prerequisites

You need a GitGuardian workspace and an API token. Reading incidents requires a token with at least the Manager access level. EU and self-hosted GitGuardian instances are also supported.

## Adding a data source

1.  In PostHog, go to the [Sources tab](https://app.posthog.com/data-management/sources) of the data pipeline section.
2.  Click **\+ New source** and click **Link** next to this source.
3.  Enter your credentials (see [Configuration](#configuration) below) and click **Next**.
4.  Select the tables you want to sync, choose a sync method and frequency, then click **Import**.

Once the syncs are complete, you can start querying this data in PostHog.

When linking GitGuardian, you'll need:

-   **API token** – create a service account token (recommended for unattended syncs) or a personal access token in your [GitGuardian API settings](https://dashboard.gitguardian.com/api). Grant the read scopes for the tables you want to sync: `incidents:read`, `sources:read`, `honeytokens:read`, `members:read`, and `teams:read`.
-   **API URL** *(optional)* – leave blank for the US SaaS instance. Workspaces on the EU instance should set it to `https://api.eu1.gitguardian.com`; self-hosted instances should enter their own API URL (must be HTTPS).

## Available tables

| Table | Description | Sync method |
| --- | --- | --- |
| `secret_incidents` | A detected secret with its triage status and remediation timeline | Incremental on `date` |
| `secret_occurrences` | A single place a secret was found (commit, file, ...) | Incremental on `date` |
| `sources` | A monitored source (repository, ...) with scan health and incident counts | Full refresh |
| `honeytokens` | Decoy credentials and whether they were triggered | Full refresh |
| `members` | Workspace members with their access level and activity | Full refresh |
| `teams` | Workspace teams | Full refresh |

**Incremental** syncs on the incident and occurrence tables use a 7-day lookback window. Rows are detected with an immutable `date` timestamp, but triage fields like `status`, `resolved_at`, and `presence` keep changing afterwards. The lookback re-reads recently detected rows each sync to pick up those late changes; merge deduplication on the row `id` prevents duplicates. Status changes on rows older than the lookback window are only recaptured by a full refresh.

**Full refresh** tables reload all data on each sync. These are typically small and have no stable timestamp to sync on.

## Sync modes

Each table can be synced in one of several modes, depending on what the source supports:

-   **Webhook** (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
-   **Incremental** – only new or updated rows are synced on each run, using a cursor field (such as an `updated_at` timestamp). Cheaper than a full refresh, but deletes aren't captured.
-   **Append only** – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
-   **Full refresh** – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.

See [sync methods](https://posthog.com/docs/data-pipelines/sources.md#sync-methods) for a full explanation of how each mode works and how to choose between them.

## Configuration

| Option | Type | Required |
| --- | --- | --- |
| `API token` | password | Yes |
| `API URL (EU or self-hosted only)` | text | No |

## Supported tables

| Table | Description | Sync method | Incremental field | Primary key |
| --- | --- | --- | --- | --- |
| `secret_incidents` | A secret incident regroups every occurrence of the same secret detected across your monitored perimeter, with its triage status and remediation timeline. | Incremental, Full refresh | date | — |
| `secret_occurrences` | A single place a secret was found: one match of an incident's secret in a specific commit, file, or other monitored location. | Incremental, Full refresh | date | — |
| `sources` | A monitored source in your GitGuardian perimeter (repository, VCS org, ...), with its scan health and open incident counts. | Full refresh | — | — |
| `honeytokens` | A honeytoken (decoy credential) created in your workspace, with its trigger status showing whether it was used. | Full refresh | — | — |
| `members` | A member of your GitGuardian workspace, with their access level and activity. | Full refresh | — | — |
| `teams` | A team in your GitGuardian workspace, used to scope incidents and sources to groups of members. | Full refresh | — | — |
| `team_memberships` | A membership of a workspace member in a team, with the permissions the member holds in that team. | Full refresh | — | — |
| `honeytoken_events` | An event recorded when someone uses one of your honeytokens, with the origin IP address and the action performed. | Full refresh | — | — |
| `secret_incident_activity_logs` | One entry in the activity history of a secret incident: a system action (assignment, status change, ...) or a user note, in chronological order. | Full refresh | — | — |
| `secret_detectors` | A secret detector GitGuardian uses to match secrets, with its category and the incident counts it produced in your workspace. | Full refresh | — | — |
| `custom_tags` | A custom tag (key/value pair) defined in the workspace and applied to incidents to organize them. | Full refresh | — | — |
| `audit_logs` | One entry in the workspace audit trail: an event performed by a member or an API token, such as a login or a settings change. | Incremental, Full refresh | date | — |
| `public_secret_incidents` | A public secret incident: a secret linked to your organization that GitGuardian found leaked in public sources, with its triage status and remediation timeline. | Incremental, Full refresh | date | — |

## Troubleshooting

-   If syncs fail with an authorization error, the token was likely revoked or expired. Create a fresh token in your GitGuardian API settings and reconnect.
-   If a specific table reports a permission error, the token is missing that table's read scope, or (for incidents) the token's access level is below Manager. Update the token's scopes and access level, then retry.
-   GitGuardian rate-limits API tokens and enforces monthly call quotas. Large initial backfills on busy workspaces may be slowed down by rate limiting; syncs back off and retry automatically.

If your sync is failing or data looks wrong, see the [Data warehouse troubleshooting guide](https://posthog.com/docs/data-warehouse/troubleshooting.md). If that doesn't help, [contact support](https://us.posthog.com/#panel=support%3Asupport%3Adata_warehouse%3A%3Atrue) – we're happy to help.