Implementing API surveys

An api survey is only a definition in PostHog. PostHog does not render it. The application renders the questions and captures the survey events. If the events or their properties are wrong, responses are missing, double-counted, or unattributed.

1. Get the survey

Fetch it with posthog:survey-get by id. Note each question's id, type, question, choices, scale and optional, plus current_iteration. Never invent question ids.

If the survey does not exist yet, create it first with the creating-surveys skill (type api). Design guidance (short, rating or choice first, open text second) lives there too. Do not restate it here.

2. Read the user's codebase

Before writing UI, find:

• The framework and the existing component library or design system. Build the survey from those components, not a generic modal.
• Where PostHog is initialized, and the installed SDK and version (package.json or lockfile, or the server language's manifest).
• Where the survey should appear. Let the app own the trigger: leave the survey's event, URL and selector conditions empty, and run the lookup below at the moment the survey should appear. getActiveMatchingSurveys only returns a survey with event conditions after that event fires, and nothing runs the lookup again at that point.

Pick the path: