Skip to main content

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.

Insito’s pricing is response-based. Every submitted response counts against your organisation’s monthly cap. Triggers, impressions, and “no survey shown” returns are free.

​
What counts

Each row inserted into the responses table = 1 against your counter. That happens when:
  • A user submits a complete or partial response from the modal (MicroSurvey.submitResponse(...)).
  • A queued offline response is flushed and accepted by the server.

​
What doesn’t count

  • MicroSurvey.trigger() calls that return survey: null (audience filter, throttling, no matching survey).
  • Impressions (/v1/sdk/impression — recorded for throttling only).
  • Failed responses (server returned a 4xx). Validation rejects don’t burn your quota.
  • Dashboard test responses (you submitting via the Preview button).

​
Plans

PlanMonthly responsesProjectsCost (USD)
Free1001$0
Pro5,0005$49/mo
Scale50,000Unlimited$299/mo
EnterpriseCustomUnlimitedContact us
Limits reset on the first day of each calendar month, anchored to UTC midnight. Usage carries over to the next billing cycle on invoice — overages are billed at the next plan’s per-response rate.

​
What happens at the limit

Insito softens plan exhaustion in three stages:
1

80% usage

Owners + admins of the organisation receive an email warning (“You’re at 80% of your Pro plan responses this month”). No user-visible change.
2

100% usage

New responses are still accepted for the rest of the day, then start rejecting with a 402 status code. The SDK’s response_failed event fires with reason: "plan_exhausted". The dashboard shows a banner.
3

Recovery

Either upgrade (admin.insito.app/billing) or wait for the monthly reset. New responses resume immediately after either action.

​
SDK behaviour when exhausted

When the plan is exhausted, MicroSurvey.trigger() still works (no quota for triggers). But submitResponse will fail with the modal showing an error toast. The response isn’t queued — there’s no point queueing something that will only re-fail. The user is returned to idle and the host app’s response_failed listener fires.

​
Querying current usage

curl -s https://api.insito.app/v1/dashboard/billing/usage \
  -H "Authorization: Bearer $JWT"
Returns: 
{
  "currentPeriod": "2026-05",
  "responsesUsed": 2347,
  "responsesLimit": 5000,
  "plan": "pro",
  "renewsAt": "2026-06-01T00:00:00Z"
}
See the dashboard’s Billing page for the human-friendly view.