Linking Cortex as a source
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.
This source is currently in alpha. The interface and available tables may change.
The Cortex connector pulls your service catalog data into the PostHog Data warehouse, so you can analyze your entities, scorecards, teams, and relationships alongside your product data.
Cortex is an internal developer portal and service catalog. It helps engineering teams track services, resources, and domains, measure them against scorecards, and manage team ownership and entity relationships.
Prerequisites
You need a Cortex account with access to create API keys. The key needs read access to the catalog, scorecards, and teams you want to sync.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- 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 Cortex, you'll need:
- API key – create an API key in your Cortex workspace under Settings > API Keys. The key needs read access to the catalog, scorecards, and teams you want to sync.
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_attimestamp). 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 for a full explanation of how each mode works and how to choose between them.
This source is full refresh only. The Cortex API doesn't expose incremental sync filters, so all tables are fully replaced on each sync.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
entities | A catalog entity (service, resource, or domain) tracked in Cortex. | Full refresh | — | — |
scorecards | A Cortex scorecard: a set of rules used to grade catalog entities against a standard. | Full refresh | — | — |
initiatives | A Cortex Initiative: a time-boxed campaign to bring entities up to part of a scorecard, with the rules or ladder levels it emphasizes. | Full refresh | — | — |
entity_types | A custom entity type (definition) available in the Cortex catalog, beyond the built-in service/domain/team types. | Full refresh | — | — |
teams | A team in Cortex, either managed directly in Cortex or backed by an identity provider group. | Full refresh | — | — |
team_hierarchies | A parent/child edge between two teams, one row per edge in the team hierarchy. | Full refresh | — | — |
relationship_types | A type of relationship (e.g. 'depends-on') that can connect two catalog entities. | Full refresh | — | — |
scorecard_scores | A single entity's score against a scorecard, one row per scorecard/entity pair. | Full refresh | — | — |
relationships | A single edge between two catalog entities for a given relationship type. | Full refresh | — | — |
users | A user in the Cortex workspace, with the profile metadata used for access reviews and for resolving entity owners. | Full refresh | — | — |
custom_events | A custom event recorded against a catalog entity, such as an incident, a migration, or a release. | Incremental, Full refresh | timestamp | — |
deploys | A deployment event recorded against a catalog entity, the grain behind deploy frequency and lead time. | Full refresh | — | — |
dependencies | A dependency edge from one catalog entity to another, optionally scoped to a single endpoint of the callee. | Full refresh | — | — |
entity_groups | One entity's membership of one group, the tagging dimension most scorecard and Initiative filters are written against. | Full refresh | — | — |
Troubleshooting
- If you see an authentication error, your Cortex API key may be invalid or revoked. Generate a new key in your Cortex workspace under Settings > API Keys, then reconnect.
- If you see a permission error, your API key doesn't have the required read permissions. Check the key's permissions in your Cortex workspace under Settings, then try again.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.