posthog/ai-plugin

setting-up-support-slack-locally

Connect a real Slack workspace to local PostHog Conversations (the SupportHog Slack app) so Slack messages become support tickets and replies post back.

Ver código-fonte
Documento original do Skill

Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.

Setting up Support Slack locally

Slack is SaaS-only, so "local" means a throwaway Slack workspace + app whose OAuth and events reach your laptop. The job has one non-obvious idea that avoids almost every wall: the OAuth connect and the event webhook have opposite reachability needs, so you point them at different places.

  • OAuth connect is browser-mediated. Your browser follows the redirect, so localhost is reachable.

No tunnel needed.

  • Inbound events (Slack POSTing messages so they become tickets) are server-to-server from Slack's

cloud. Slack cannot reach localhost, so this one needs a public tunnel.

Keep the whole app and the OAuth flow on localhost, and point only Event Subscriptions (and Interactivity) at the tunnel. This also sidesteps free-tier tunnel rate limits, since the tunnel then carries only Slack's low-volume event POSTs rather than the entire SPA.

This is the conversations/SupportHog variant of the general Slack local setup guide; that guide covers the PostHog Desktop / notifications Slack app (SLACK_APP_*, /integrations/slack/callback). Conversations uses its own SUPPORT_SLACK_* credentials and /api/conversations/v1/slack/* routes, but the tunnel and SITE_URL mechanics are identical.

The endpoints

All under products/conversations/backend/api/urls.py, prefixed /api/conversations/:

RoutePurposeReachability
v1/slack/authorizereturns the Slack OAuth URL (auth-gated)browser (localhost)
v1/slack/callbackOAuth redirect target; built from SITE_URL, no forced httpsbrowser (localhost)
v1/slack/eventsinbound event webhookSlack's servers (tunnel)
v1/slack/interactivityinteractive component callbacksSlack's servers (tunnel)

The callback requires an authenticated session on whatever origin SITE_URL resolves to, because the session cookie is per-origin. Keep SITE_URL on localhost and log in there, and the callback keeps your session.

Step 1 — credentials

SUPPORT_SLACK_APP_CLIENT_ID, SUPPORT_SLACK_APP_CLIENT_SECRET, and SUPPORT_SLACK_SIGNING_SECRET are django-constance dynamic settings (posthog/settings/dynamic_settings.py) that default to the matching env var. Empty client id is what produces "Support Slack OAuth client ID is not configured". Put your Slack app's values in .env.local (gitignored) and restart the backend:

bash
SUPPORT_SLACK_APP_CLIENT_ID=<client id>
SUPPORT_SLACK_APP_CLIENT_SECRET=<client secret>
SUPPORT_SLACK_SIGNING_SECRET=<signing secret>

Constance stores values in the DB, and a stored value overrides the env default. If it still reads as unconfigured after a restart, check /admin/constance/config/ for a blank stored value and set it there instead.

Step 2 — the Slack app

At api.slack.com/apps, create an app in a throwaway workspace, then:

  1. App Home → enable a bot user (give it a display name). Without this, install fails with "requesting

permission to install a bot ... but it's not currently configured with a bot".

  1. OAuth & Permissions → Bot Token Scopes — the flow requests these (from SUPPORTHOG_SLACK_SCOPES in

products/conversations/backend/api/slack_oauth.py): channels:history, channels:read, chat:write, chat:write.customize, files:read, files:write, groups:history, groups:read, reactions:read, users:read, users:read.email. Attachments need the two files: scopes in both directions, so a workspace installed without them shows a "reconnect" banner in support settings.

  1. OAuth & Permissions → Redirect URLs — add http://localhost:8010/api/conversations/v1/slack/callback

and Save. If Slack refuses a plain-http localhost URL, use the tunnel URL for the callback too and log in once on the tunnel origin (see references/troubleshooting.md).

  1. Copy the Client ID, Client Secret, and Signing Secret from Basic Information into .env.local (Step 1).

Step 3 — tunnel for inbound events

Run any HTTPS tunnel pointed at Caddy on 8010, rewriting the upstream Host header to localhost (the dev Caddy only answers for the localhost host; without the rewrite you get an empty 200 and a white page):

bash
ngrok http --host-header=localhost 8010
# or, free with no rate limit:
cloudflared tunnel --url http://localhost:8010 --http-host-header localhost

Verify it reaches Django, not just Caddy:

bash
curl -sS https://<tunnel-host>/_preflight | head -c 120   # want JSON, server: granian

Then in the Slack app set Event Subscriptions → Request URL (and Interactivity → Request URL if testing buttons) to https://<tunnel-host>/api/conversations/v1/slack/events (and .../interactivity). Slack sends a synchronous url_verification challenge on save, so the backend must be up; the handler echoes it back automatically.

The Request URL alone only passes verification; it delivers nothing until you subscribe to events. Under Event Subscriptions → Subscribe to bot events, add the events the backend handles (SUPPORT_EVENT_TYPES in products/conversations/backend/api/slack_events.py):

  • app_mention
  • message.channels (and message.groups for private channels), both arriving as the inner message event
  • reaction_added
  • member_joined_channel, member_left_channel

Reinstall the app after changing scopes/events so the new grants take effect.

Step 4 — connect and test

Browse the app at http://localhost:8010, log in, go to Support settings, and connect Slack. The OAuth round-trip completes on localhost. Then invite the bot to a channel in your dev workspace and post a message; it should arrive as a ticket, and a reply from the ticket should post back to the thread.

For the failure modes worth recognizing (white screen, "Network error", redirect mismatch, region routing), see references/troubleshooting.md.

do mesmo repositório

Mais Skills

Todos os Skills
posthog
Oficial

assessing-heatmaps

Assesses what a page's heatmap is telling you and recommends concrete changes. Pulls click / rageclick / scroll-depth data for a URL, names the hot elements by cross-referencing autocapture events on the same page, and can create a saved heatmap the user opens in PostHog, then summarizes the behavior and proposes improvements.\nTRIGGER when: user asks what a heatmap shows, why people aren't clicking something, where users rage-click, how far they scroll, what to change on a page based on heatmap/click data, or to 'analyze/assess/review the heatmap' for a URL.\nDO NOT TRIGGER when: the user only wants to create a saved heatmap screenshot with no analysis (use heatmaps-saved-create directly), or is asking about session replay in general (use investigating-replay).

instalações
1
GitHub Stars
80
Atualizado
4 de set.
posthog
Oficial

auditing-endpoints

Audit every endpoint in a PostHog project for staleness, failed materialisations, and unused materialised versions. Use when the user asks "what endpoints can I clean up?", "are any of my endpoints broken?", "which materialised versions are still being called?", or wants a one-shot cleanup pass over the Endpoints product. Produces a prioritised report grouped by issue type, with recommended actions but does not modify anything without explicit confirmation.

instalações
1
GitHub Stars
80
Atualizado
4 de set.
posthog
Oficial

auditing-experiments-flags

Audit PostHog experiments and feature flags for configuration issues, staleness, and best-practice violations. Read when the user asks to audit, health-check, or review experiments or feature flags, check flag hygiene, or verify experiment setup.

instalações
1
GitHub Stars
80
Atualizado
4 de set.
posthog
Oficial

authoring-data-quality-checks

Adds and runs data quality checks (dbt-test style assertions) on a project's warehouse tables and saved-query views: not-null, uniqueness, accepted values, referential integrity, row-count bounds, freshness, and custom HogQL. Use when asked to test a model, validate a view, check for nulls or duplicates, add data quality checks, find out why a number looks wrong, or judge whether a warehouse table is trustworthy before using it in an analysis. To describe what data means (metrics, certifications, joins), see setting-up-data-catalog instead. Trigger terms: data quality, data test, dbt test, not null check, uniqueness check, freshness check, referential integrity, row count check, validate model, is this table trustworthy.

instalações
1
GitHub Stars
80
Atualizado
4 de set.