Skip to main content
Insito’s pricing is response-based. Each paid plan sets a monthly response cap that is enforced per app (project), not across your whole organisation. Triggers, impressions, and “no survey shown” returns are free.

​
What counts

A response counts the first time a row is written to the responses table for an app in the current calendar month. That happens when:
  • A user submits a complete response from the modal (MicroSurvey.submitResponse(...)).
  • A partial/autosave response is first persisted (POST /v1/sdk/responses). Later autosave updates to the same response don’t count again.
  • A queued offline response is flushed and accepted by the server.

​
What doesn’t count

  • MicroSurvey.trigger() / evaluate calls that return survey: null.
  • Impressions (/v1/sdk/impression — recorded for throttling and show caps).
  • Responses rejected with a 4xx (e.g. validation failures).

​
Plans

Response caps are per app. Paid plans (Starter, Growth, Studio) can purchase additional apps as an add-on, which increases the number of apps included in the subscription. Limits reset on the first day of each calendar month at UTC midnight.

​
What happens at the limit

When an app reaches its monthly cap, enforcement is immediate — there’s no end-of-day grace:
1

80% usage

Organisation owners receive an email warning that the app is approaching its monthly response cap. No user-visible change.
2

100% usage

POST /v1/sdk/response returns 402 with { "error": "response_limit_reached", "upgradeUrl": "...", "projectId": "..." }. The SDK’s response_failed event fires with reason: "response_limit_reached", and the response is not queued for retry.
3

Recovery

Upgrade the plan (or add an app) from app.insito.io/settings/billing, or wait for the monthly reset. New responses are accepted immediately after either.

​
SDK behaviour when exhausted

When an app is over its cap, MicroSurvey.trigger() still works (triggers are free) and the modal can still be shown. But submitResponse fails with an error state. Because a re-submit would only re-fail, the response isn’t queued — the user returns to idle and the host app’s response_failed listener fires with reason: "response_limit_reached".

​
Querying current usage

Organisation-wide aggregate:
Per-app usage (the value the SDK cap is checked against):
See the dashboard’s Plan page for the human-friendly view.