Throttling prevents a single user from being asked the same question over and over. Insito’s default is 28 days per (survey, userId), matching the industry-standard NPS recurrence window.Documentation Index
Fetch the complete documentation index at: https://docs.insito.app/llms.txt
Use this file to discover all available pages before exploring further.
How the window works
When a user submits a response to a survey (or dismisses the modal), Insito records theseen_at timestamp on a per-user, per-survey
basis. The next time the user fires the matching trigger, the API
checks now() - seen_at < cooldown_days. If true, the API returns
survey: null and the SDK silently returns to idle.
Implications:
- An impression (modal shown but dismissed) counts as “seen”. Users who close the modal without answering still get the 28-day pause.
- A failed response (validation error, plan-limit reject) does not count — those users can retry.
- An abandoned response (user backgrounds the app mid-survey) counts as a dismissal once the modal unmounts.
Tuning the window
Edit the survey, change the Cooldown days field, save. Takes effect on the next trigger call. Recommended settings:| Scenario | Cooldown | Rationale |
|---|---|---|
| Standard NPS | 28 days | Industry default; users won’t notice. |
| Beta funnel | 7 days | Faster iteration on small cohorts. |
| Manual feedback (“Send feedback” button) | 1 day | User-initiated, mostly self-throttling. |
| Onboarding effort | 90 days | One-time event; high cooldown avoids re-asking on app re-installs. |
Cross-survey interactions
Throttling is per-(survey, userId). Two different surveys can
fire on the same user the same hour — they’re independent.
If you want a global cooldown (“don’t ask this user anything
for 14 days after they answered a survey”), today you’d need to
implement it client-side via your own state. We’re tracking this as
[INS-…] (cross-survey throttling). Let us know if you need it.
Override for testing
There’s no API to bypass throttling in production — it’s a hard invariant. For local development:- Use a test API key (a separate project).
- Pass different
userIds inMicroSurvey.identify()per session. - Or: drop the test user from the dashboard’s Project → Settings → Reset throttling action (admin-only).