Subscriptions and trials
How to subscribe to a tool, what the 14-day trial gives you, and what happens when the trial ends.
What a subscription covers
A subscription is a commitment to pay monthly for access to one or more tools at one or more access tiers. Access tiers are per-tool; today most tools offer a Basic tier (interactive use in the app) and a Pro tier (programmatic access over REST and MCP). Each tier has its own price, so a team that needs both will see two line items for the same tool on their invoice.
Once a subscription is active, the billing tab shows a Your subscription card that lists each tool, the tier the org is paying for (Basic or Pro), and the exact price on the org’s current Stripe subscription — which may differ from today’s published price if the org subscribed before a price change.
If a discount applies to the subscription, the card shows what you actually pay. A percentage discount is applied to each tool line, with the list price struck through beside it — AU$99/mo AU$0/mo, captioned with the discount and how long it lasts. A fixed-amount discount reduces your invoice as a whole rather than any one tool, so the per-tool lines stay at their list price and the card says explicitly that the amounts are shown before the discount.
Subscriptions are scoped to a single Stripe customer — either your personal account or one of your team orgs — and they provision entitlements for exactly the users belonging to that customer.
Subscribing to a tool for the first time
The first subscription for any workspace goes through Stripe Checkout, the standard hosted checkout flow. From either the Account Settings Billing tab (for your personal workspace) or the Organization Settings Billing tab (for an org), toggle one or more tools to a paid tier and click Save Changes. The app opens an embedded Stripe Checkout dialog where you confirm the purchase. When Checkout finishes, control returns to the billing tab and the subscription is usually active within a few seconds.
Checkout also has a promotion code field. If you have been issued a code — for example as a beta tester — enter it there and the discount is applied to the subscription before it is created. Checkout only asks for card details when there is a non-zero amount due at that moment, so a code that brings the total to zero completes without collecting a card. See The 14-day trial below, which has the same effect.
Under the hood the flow is: the client asks POST /api/billing/checkout to create a Checkout Session, Stripe redirects through its hosted UI, and Stripe’s checkout.session.completed webhook tells our backend to provision the entitlements. The billing tab polls again after roughly three seconds to catch the webhook round-trip — if you see the UI update to “active” shortly after Checkout, that’s what you’re watching.
The 14-day trial
Every first subscription for a given Stripe customer receives a 14-day trial. The trial is provisioned by Stripe — not by our backend — so eligibility is determined against Stripe’s view of the customer, not our database:
- A Stripe customer that has never had any subscription (active, cancelled, trialing, or otherwise) gets the trial on their first subscribe.
- A customer that has had a subscription before — even a cancelled one — does not get another trial.
The trial length constant lives in both the client and the Stripe subscription create call, kept in lockstep so the progress UI matches what Stripe is charging.
During the trial, entitlements are provisioned exactly as if the subscription were active — there is no “trial mode” on the tools themselves. You will see a trial status card on the billing tab showing days remaining and the end date.
No card is collected when you start a trial. Because a trial makes the amount due at checkout zero, Stripe does not ask for payment details — so you can start a trial without entering a card at all. Add one from the billing tab before the trial ends (see Payment methods and invoices); what happens if you don’t is covered next.
What happens when the trial ends
If a card is on file, Stripe charges it on the trial end date. If the payment succeeds, the subscription transitions from trialing to active and entitlements continue uninterrupted. If the payment fails, the subscription enters past_due (see below) and entitlements are revoked until the card is updated and the invoice paid.
If no card is on file, the subscription is paused rather than charged. Nothing is billed and no unpaid invoice is raised, but the subscription stops being active, so entitlements are revoked and the tools become inaccessible until you add a payment method. This is deliberate: being quietly moved into a failed-payment state over a card you were never asked for would be worse than being told plainly that access has stopped. Your saved work is untouched — add a card from the billing tab to restore access.
If you want to cancel before being charged, follow the steps in Cancelling and reactivating. Cancelling during the trial schedules the subscription to end at the current period end (which, during a trial, is the trial end date itself) — so you keep access for the remainder of the trial and are never charged.
Past-due and unpaid states
If Stripe cannot collect payment on renewal — expired card, insufficient funds, fraud block — the subscription enters past_due immediately and our backend revokes entitlements on the spot. There is no grace period. Users whose access came from that subscription will lose their entitlements within seconds of the webhook firing.
A failure notification email is sent to the org’s billing email address the first time payment fails each day, rate-limited to once per 24 hours per org so a retry loop cannot flood your inbox.
To recover, update the payment method (see Payment methods and invoices) and Stripe will automatically retry the latest invoice. Once the invoice is paid, the subscription returns to active and the entitlement reconciliation webhook re-provisions access.
Access tiers in practice
Most tools expose two tiers today:
- Basic — access to the tool through the Integraph app in a browser. This is what engineers use day-to-day for drawing sections, running checks, and generating reports. Currently priced at AU$15/month for new subscribers.
- Pro — access to the same analysis engine via REST endpoints and the MCP server. This is useful for automating report generation, integrating into BIM tooling, or driving the analysis from a scripting environment. Currently priced at AU$20/month for new subscribers.
Subscribers who joined before the June 2026 price update are grandfathered at their original price for as long as the subscription remains active. If you cancel and resubscribe, the current published price applies.
A user can hold both tiers for the same tool simultaneously — in fact, an org that wants its engineers to use the app day-to-day and its automation to call the API will subscribe to both the Basic and Pro tiers: a Basic entitlement alone is not enough to authenticate an API call. The billing tab’s per-member tree lets you pick which tiers each member gets individually.
Tiers are resolved by Stripe price ID (not by tool slug), which is what lets a single org subscribe to the Basic and Pro tiers for the same tool as two independent line items. That price-ID-keyed model is what makes the reconciliation logic on the Managing org entitlements page possible.
How API tier usage is metered
The Web tier is a flat monthly charge — once a user has the entitlement they can use the tool in the browser as much as they like. The API tier behaves differently: the subscription gives you the right to call the API and MCP, and each call is then metered against a per-user AUD balance. The model is designed for predictable cost with a hard stop, not unlimited usage.
The same balance covers all metered endpoints across every tool. A heat-transfer analysis, an LGS check, and a concrete capacity calculation all draw from the same pool — there is no per-tool sub-balance to manage. Live per-endpoint prices are published on the API & MCP page and on the GET /api/billing/api-costs discovery endpoint.
The included allowance
Each user with at least one Pro entitlement gets an allowance of AUD credit at the start of every billing period. The allowance scales with the number of distinct active Pro entitlements that user is paying for: a user subscribed to one tool’s Pro tier receives the base allowance; a user with three Pro entitlements receives three times that allowance. The exact per-entitlement value is published on the API & MCP page — it is not hard-coded into this documentation because it is calibrated against real usage and may be re-tuned during the early launch period.
Allowances do not roll over. Each billing period starts fresh — unused balance from last month is replaced, not added on top.
When the balance runs out
When a metered call would take the balance below zero, the API returns HTTP 402 Payment Required with code: api_balance_exhausted. The call is refused; no charge is incurred; the request is not retried automatically. The block lifts when one of two things happens:
- The next billing period rolls over and the allowance refills.
- A top-up is approved and the purchased credit is granted.
There is no overage charge and no automatic top-up. This is deliberate — it bounds the worst-case spend a runaway script or a misconfigured agent can incur.
Top-up workflow
If a user runs through their allowance partway through a billing period, they can request a top-up. The flow has four stages:
- Request. The user requests a top-up from the in-app exhaustion dialog (or from the API at
POST /api/billing/api-usage/top-ups). The request specifies an AUD amount within the configured min and max. - Approval. The request is routed to the billing owner of the user’s billing org. For a user on a personal Pro plan, that is the user themselves. For a user on a team org’s Pro plan, the request goes to the team org’s billing owner, who approves or rejects it from the billing tab.
- Stripe Checkout. On approval, the billing owner is taken to a Stripe Checkout session for the approved amount. Payment goes through the org’s saved card.
- Grant. When Stripe confirms payment, the AUD amount is added to the requesting user’s balance. The user can resume API calls within seconds.
A pending top-up request expires after a configurable window (default seven days) if not approved.
Multi-Pro-org users and the billing org
A single user can hold Pro entitlements from more than one org — for example, an external consultant who has been granted Pro access in two different client teams. The platform handles this by designating exactly one of those orgs as the user’s billing org for API metering. The user has a single balance; refills are funded against the billing org’s subscription; top-ups (if any) are paid by the billing org’s card. The designation is automatic and stable — the user does not have to choose. Other orgs continue to pay for the Pro entitlement itself, but they do not double-pay the metering allowance.
Tracking usage
The balance, recent ledger entries, and projected period-end refill are visible on the billing tab. Every metered API response also carries three headers that scripts and agents can read directly:
X-Api-Cost-Micro-Dollars— the cost of this call in AUD micro-dollars ().X-Api-Balance-Micro-Dollars— the balance remaining after the call, in the same unit.X-Api-Period-End— ISO-8601 timestamp of the next allowance refill.
See the API & MCP page for the developer-side surfaces — discovery endpoint, OpenAPI cost badges, and MCP tool description suffixes — that let automation and AI agents reason about cost before they make a call.