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).
  • A retried submit with an Idempotency-Key that was already recorded (the SDKs send one from 0.2.4), so retries after a timeout never count twice.

Plans

Response caps are per app. Paid plans (Starter, Growth, Enterprise) 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 keeps the answers in its offline queue (up to 7 days) and fires response_queued.
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. From SDK 0.2.4, submitResponse keeps the answers in the offline queue instead of discarding them: the modal closes as usual and response_queued fires. The queue doesn’t retry on a timer while the cap is hit. It tries again when the app returns to the foreground or is relaunched, and delivers the answers once there’s room (after an upgrade or the monthly reset). Answers still queued after 7 days are discarded. SDKs before 0.2.4 don’t queue at the limit: submitResponse fails, the user returns to idle and response_failed 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.