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), set your tax location if you have not already (see Tax location below — Save Changes stays greyed out until you do), toggle one or more tools to a paid tier, and click Save Changes. The app opens an embedded Stripe Checkout dialog. Checkout collects your payment details, a billing address, and optionally a tax ID (an ABN in Australia, a VAT number in the EU or UK). The tax ID field is not on the form by default: tick I’m purchasing as a business and a Business name and Tax ID pair appears beneath it. When Checkout finishes, control returns to the billing tab and the subscription is usually active within a few seconds.

:::caution[Who you are buying from, and what your statement will say] On most purchases Link, a Stripe service, is the merchant of record. Link takes the payment, calculates, collects and remits any GST, VAT or other sales tax under its own registrations, and issues your receipt and tax invoice. Integraph remains the supplier of the software, and is named as such on the invoice Link issues.

The practical consequence is the line on your card or bank statement: it reads LINK.COM* INTEGRAPH, not Integraph. Check for that before reporting the charge as unrecognised.

This arrangement is also what opened self-serve checkout to the European Union and the United Kingdom in September 2026 — the VAT liability there is Link’s rather than ours, so no registration of our own is needed. If you are registered for VAT or GST, tick I’m purchasing as a business in Checkout and enter your number in the Tax ID field that appears, so it reaches the invoice Link issues. :::

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. Card details are always collected, even when a code brings the total to zero. Nothing is charged against that card while the discount covers the full amount; it is collected so the subscription can convert on its own if the discount ever ends or the amount due becomes non-zero.

Under the hood the flow is: the client asks POST /api/v1/organizations/{organizationId}/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 same request creates the Stripe customer record for the workspace if one does not exist yet, and stamps your tax location onto it. That is what lets Stripe work out the tax before the checkout dialog first renders, rather than partway through it — and it is why the location is required rather than optional.

The same request also fixes the currency of the session, from that tax location, for each of the markets we price in directly. So the figure Checkout asks you to approve is the one the billing tab quoted you, and neither depends on where you happen to be sitting when you open the dialog — a consultant working abroad is charged their workspace’s price, not the local one.

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.

Your card is collected when you start a trial. Checkout asks for payment details even though the amount due that day is zero, so the subscription can convert on its own when the trial ends. Nothing is charged until the trial end date. You can change the card at any time from the billing tab (see Payment methods and invoices), and cancelling before the end date means you are never charged at all.

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 usable card is on file — normally because the card was removed during the trial, since one is collected at checkout — 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 with nothing to charge 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.
• 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.

Current per-tier prices are on the pricing page, which quotes them in your market’s currency. They are deliberately not restated here: this page is one build for every reader, so a figure written into it would be the Australian one shown to everyone — a false statement about price in twenty-five of the twenty-six markets we price in.

Prices are exclusive of tax. The tax rate is determined from your tax location and the billing address you supply at checkout — GST, VAT or the equivalent sales tax for your location is calculated and shown as a separate line before you confirm, so the total you approve is the total you are charged. An Australian customer, for example, pays 10% GST on top of the listed price. To put your ABN, VAT number or other tax ID on the tax invoice, tick I’m purchasing as a business in Checkout and enter it in the Tax ID field that appears — the field is hidden until you tick that box, so there is nothing to fill in until you do.

Tax location

Set your tax location on the billing tab. It is required before checkout will open: without it we cannot work out what tax you owe, and quoting you a total we could not stand behind is worse than asking for one more field. Save Changes stays disabled, with the reason shown beside the selector, until a country is set.

The setting is a country, not a full address; that is all Stripe needs outside the United States, Canada and India, which resolve tax from state, province or postal code and so still rely on the address collected at checkout.

EU and UK countries check out normally — see Who you are buying from above. Set the country you are actually established in rather than a neighbouring one: the address you type inside Checkout is what Stripe files the transaction against either way, so a mismatch does not get you a better tax outcome, it gets you an incorrect tax record.

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.

tool_not_in_plan

A request touched a tool that your organisation’s plan does not include. The response is HTTP 403 Forbidden with code: tool_not_in_plan, titled “Tool not included in your plan”; the detail says your subscription does not include access to the tool and names the tool on the API compute routes.

The gate is org-scoped: the entitlement must be granted by the organisation that owns the project or design option you are working in, or platform-wide. A seat granted by one organisation does not unlock the same tool inside another organisation’s project. Creating a tool instance in a project is refused the same way, in the app and by the CreateToolInstance MCP tool.

On the API and MCP surfaces the tier matters as well as the tool: an API key or MCP session calls a tool’s endpoints only with a Pro entitlement for that specific tool. A Basic entitlement unlocks the browser app and never the API, and a Pro entitlement on one tool never unlocks another’s, so a Basic-only subscriber calling the REST or MCP surface receives this code.

To resolve it, ask an owner of the organisation to add the tool — at the Pro tier for API and MCP use — on the billing tab (see Managing org entitlements), or move the work to an organisation that holds it. This is a different state from api_balance_exhausted, which means the entitlement exists and its metered allowance has run out: that one answers 402, this one 403.

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 an AUD balance held per (user, organisation). Every organisation that grants you an API-tier seat funds its own balance for you, and they are never pooled. The model is designed for predictable cost with a hard stop, not unlimited usage.

Within one organisation, that 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/v1/billing/api-costs discovery endpoint.

An API key belongs to one organisation, so a call made with that key always meters against that organisation’s balance — never another’s. In the browser, the balance chip in the header shows the balance of the organisation you are looking at — the active workspace normally, and on an organisation’s settings page that organisation, so following a link to another org’s billing tab shows you that org’s balance rather than your workspace’s. The chip names the organisation it is reporting. It is hidden entirely where you hold no API-tier seat.

:::note[The whole API surface is metered — September 2026 (#6178)] Project, design, design-option, element and reference-catalogue endpoints used to be free to call with an API key; they are now metered at a new low CRUD bucket, one bucket below the cheapest analysis call. Nothing about browser use changes, and no existing price moves — this adds a price where there was none. Check any integration that polls, and make sure your client handles 402 api_balance_exhausted on every route rather than only on analysis calls. See Which endpoints are metered. :::

Which endpoints are metered

Every REST endpoint on the API is metered, not only the analysis ones. Reading, creating and updating projects, designs, design options and elements is charged, as are the reference catalogues (jurisdictions, tool definitions, grades, stress-strain models, EPD records) — and so are the account endpoints: sign-in and session, profile and MFA, organisations and members, API keys, and billing itself. These are priced at the lowest bucket — a small fraction of an analysis call — because they run no solver, while a few that do real work (cloning or promoting a design option, design-option metrics, refreshing material snapshots) sit one bucket higher. Live per-endpoint prices are on the API & MCP page and on GET /api/v1/billing/api-costs; treat that catalogue, not this page, as the authority on any individual number.

Two consequences worth planning for:

• A polling integration now costs something. A script that lists projects on a loop used to be free and is not any more. The amount is small, but budget for it and prefer webhooks or a longer poll interval where you can.
• 402 Payment Required can now come back from any route. Before this change it was reachable only from an analysis or report call. Handle code: api_balance_exhausted on every request your client makes, not just the expensive ones.
• You cannot top up, or even read your balance, from the API once it hits zero. The billing endpoints are metered like everything else, so at zero balance GET /api/v1/billing/api-balance, the top-up request and the checkout endpoints all return 402 as well. The MCP tools are metered too, so GetApiBalance over MCP returns the same refusal — there is no programmatic way round it on either surface. Recovery is through the app in a browser, where nothing is metered — sign in, open the billing tab, and top up there. This is deliberate rather than an oversight, and it is the one case worth designing for explicitly: if your integration is unattended, alert on a falling balance before it reaches zero rather than relying on catching the 402, because by then the programmatic remedy is gone too.

The MCP tools are metered too. Every priced MCP tool now charges the price its tools/list description advertises — previously that price was published and never collected. The cost matches the REST endpoint the tool wraps, so an agent pays the same for ListProjects as a script paying for GET /api/v1/projects, and the same goes for account-management tools now that their REST peers are metered: organisation and member reads, preferences and the balance and price lookups are all at the lowest bucket. The only MCP tools that are free are the operator observability ones, which have no REST endpoint behind them at all. See the MCP page for how the charge is reported back to your agent.

Browser use is never metered. The balance funds programmatic access only — the meter reads your API key, so using the tools in the app draws nothing from it, at any tier. That includes MCP: a session authenticated as a browser user, rather than with an API key, is never charged.

The public catalogues stay free to anonymous callers. Jurisdictions, tool definitions, grades and stress-strain models are public and need no credential; they are only charged when called with an API key. (EPD records are not in that set — those reads require authentication, so they are always charged.) That means an API-key holder can fetch them free by simply leaving the Authorization header off. We would rather say so than publish a price that is trivially avoidable — but do not build on it as a guarantee: it is a consequence of those routes being public, and if a future change closes public access the charge becomes unavoidable with it.

The included allowance

Each balance gets an allowance of AUD credit at the start of every billing period. The allowance scales with the number of distinct active Pro entitlements the granting organisation is paying for on that user’s behalf: one tool’s Pro tier from that org receives the base allowance; three Pro entitlements from that org receive three times that allowance. Grants from a different organisation count towards that organisation’s balance, never this one. 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 for each balance — 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 balance runs out partway through a billing period, the user can request a top-up. A top-up targets one named organisation — the one whose balance is exhausted — and the request carries that organisation explicitly. The flow has four stages:

1. Request. The user requests a top-up from the in-app exhaustion dialog (or from the API at POST /api/v1/billing/api-usage/top-ups, where organizationId is a required field). The request carries a suggested credit amount for the owner to act on. Naming an organisation that grants you no API-tier seat is refused, not redirected to one that does.
2. Approval. The request is routed to the owners of that organisation — the ones whose budget the payment comes from. If the requester is themselves an owner of it, they go straight to checkout; otherwise the owners approve or reject from the billing tab.
3. Stripe Checkout. On approval, the owner picks one of the fixed credit packs and is taken to a Stripe Checkout session for it. Payment goes through that organisation’s saved card. The pack is a real catalogue price, so Stripe presents it in the buyer’s own currency where we publish one.
4. Grant. When Stripe confirms payment, the pack’s credits are added to that organisation’s balance for the requesting user — the same number of credits whichever currency it was paid in. They can resume API calls against that organisation within seconds.

A pending top-up request expires after a configurable window (default seven days) if not approved.

Users with Pro seats in more than one org

A single user can hold Pro entitlements from more than one org — for example, an external consultant granted Pro access in two different client teams. Each of those orgs funds its own balance for that consultant: separate allowances, separate top-ups, separate period resets. There is no “billing org” designation and nothing to choose — a metered call is always charged to the organisation whose API key made it, so no org ever pays for another’s usage.

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-Credits — the cost of this call, in API credits.
• X-Api-Balance-Credits — the credits remaining after the call.
• X-Api-Period-End — ISO-8601 timestamp of the next allowance refill.

One credit is one AUD micro-dollar, so 1,000,000 credits is one Australian dollar. The endpoint publishes that rate as creditsPerAustralianDollar on GET /api/v1/billing/api-costs, so nothing needs to hard-code it.

The earlier X-Api-Cost-Micro-Dollars and X-Api-Balance-Micro-Dollars headers are still sent alongside the credit ones and carry exactly the same numbers. They are marked deprecated in the API reference and stop being sent on 31 March 2027; read the credit names instead. The same applies to the balanceMicroDollars and costMicroDollars fields in an out-of-balance response body, which now also come as balanceCredits and costCredits.

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.