Skip to content
Wicket

Entity harvesting and freshness

Policies that say “only these repos”, “only public repositories”, or “only this Linear team” need to know what your repos, channels, and teams actually are. Entity harvesting is how Wicket collects that metadata from your connected services — and freshness is how it stays true as your workspace changes.

What gets harvested

Harvesting covers every connector except Prowler. A few connectors illustrate the kinds of entities and attributes collected:

ServiceEntities
GitHubRepositories (visibility, archived state, topics), pull requests, issues (state, labels, draft/locked), branches (protected, default), releases
SlackChannels (private, archived, shared)
LinearTeams, projects, issues (state, priority, labels)
VercelProjects and deployments (target, state, visibility)

The same machinery also harvests Notion, Stripe, Supabase, HubSpot, Airtable, PlanetScale, Atlassian, Sentry, Cloudflare, Hugging Face, and Google — names, IDs, and the metadata your pickers and resource conditions need.

Harvested entities power two things:

  1. Pickers — when you add a repo restriction or channel restriction in the policy builder, the dropdown is your harvested data.
  2. Resource-condition evaluation — a policy matching visibility: public checks the harvested attributes of the repository a call targets. See the full condition list.

Only metadata is harvested — names, IDs, and the attributes above. File contents, message bodies, and issue descriptions are never collected.

How entities stay fresh

Wicket layers three mechanisms, preferring the cheapest one available for each connection:

1. Webhooks (preferred). Eleven connectors can push change events to Wicket: GitHub (via App mode or your app’s webhooks), Vercel, Airtable, Slack, Linear, Stripe, HubSpot, Notion, Sentry, Hugging Face, and Atlassian. A renamed channel, a merged PR, or a new deployment updates the harvested record within seconds — no polling. Whether a connection is actually webhook-fresh depends on its credentials:

  • Always on — Vercel (every delivery is signed with the OAuth client secret) and Airtable (per-scope webhook secret) push without extra setup.
  • Slack, Linear — webhook-fresh out of the box when Wicket manages the OAuth app. With your own OAuth app, add your webhook signing secret in the connector settings to keep them webhook-fresh (Linear can register its webhooks automatically when you save credentials; clearing the secret tears them down). Without that secret the connection runs degraded and falls back to request-time harvesting.
  • Stripe, HubSpot, Notion, Sentry, Hugging Face — webhook-fresh only once a webhook secret is configured (an environment secret, your own app’s webhookSecret, or — for Notion — a per-subscription registration secret captured automatically). Otherwise the connection runs degraded.
  • Atlassian — webhook-fresh once a per-connection registration secret and external ID exist for the connection.

When a connection isn’t webhook-capable (or is degraded), Wicket falls back to the request-time and background mechanisms below.

2. Request-time refresh. When a tool call targets a resource whose record is stale or missing, Wicket fetches that one resource live — using the calling member’s own token — so resource conditions evaluate against current attributes rather than an old snapshot.

3. Background harvest. For connections without webhook coverage — including Supabase, PlanetScale, Cloudflare, and Google, which harvest only via request-time fetch and scope resolution — Wicket performs an initial backfill after connect and refreshes in the background while the connection is in use.

Check freshness in the dashboard

Each service connection shows a harvest status — idle, pending, running, or failed — and a last harvested timestamp. Policy pickers surface the same signal, so you can tell whether the channel list you’re choosing from is minutes or weeks old, and trigger a re-harvest from the connection panel when you need it now.

When data is stale anyway

A resource created seconds ago, a connection whose webhook secret was never configured, a failed harvest — staleness happens. The implications:

  • Pickers may not list the newest resource yet — re-harvest, or use an owner-level restriction (e.g. owner: my-org matches future repos too).
  • Attribute conditions evaluate against what’s known; the request-time refresh covers the common case of a single targeted resource.

For restrictions that must hold regardless of harvest state, prefer structural scoping (owners/orgs, teams) over per-entity enumeration.