billing block on your application config:
src/application-config.ts
recurring— flat and per-member fees the platform raises for you, once per billing period.operations— what you charge for as you use it, from a logic function.description— one friendly line shown to buyers on your marketplace listing.
Recurring charges
A recurring charge is a subscription fee: a flat monthly amount, an amount per workspace member, or both. You declare the amount and the platform charges it. Your app never callschargeCredits for these.
src/application-config.ts
How they are raised:
- Once per workspace billing period, on the workspace’s own period boundary, not on the first of the month.
- Not prorated. An app installed mid-period is charged the full amount for that period; uninstalling stops the next period, it does not refund the current one.
- Per-member charges count all workspace members at the moment the charge is raised, so a workspace that grows mid-period pays the higher count from the next period.
- Only on monthly subscriptions. A workspace on a yearly plan is not charged a
MONTHfee, rather than being charged once for the whole year. - Bounded. A declared rate above $100, or a per-member charge whose rate multiplied by the member count would exceed $1,000 for the period, is refused and not raised. The platform raises these itself, so it will not write a debit it cannot justify.
Billable operations
An operation is what your app charges for as it works. Each entry maps an operation name you choose onto the billing category the platform meters, plus the label shown to workspace admins in Settings > Usage.src/application-config.ts
operationType must be one of the platform’s billing categories: AI_CHAT_TOKEN, AI_WORKFLOW_TOKEN, WORKFLOW_EXECUTION, CODE_EXECUTION, WEB_SEARCH, CALL_RECORDING, EMAIL_SEND. It decides how the spend is metered and which counting unit applies (tokens, invocations, minutes) — it is not what admins read. The label is.
The build rejects an unknown operationType, an empty label, and a name used by both a recurring charge and an operation.
Charging
Charge against a declared operation by name:creditsUsedMicro is the amount in micro-credits (1 USD = 1,000,000). quantity is how many units the charge covers, in the unit implied by the operation’s category — minutes for CALL_RECORDING, invocations for CODE_EXECUTION, and so on.
Notes:
- Declaring operations is what lets Usage split your app’s spend by what it charged for. An app that declares nothing is still reported, as a single slice under its display name.
- Charging an operation your manifest does not declare is rejected. Add it to
billing.operationsand sync. - Several operations may share one
operationType. Two enrichment operations both metered asCODE_EXECUTIONstill show as two labelled slices. - Without
operation, name the billing category directly withoperationType, optionally with a free-formresourceContext. The two forms are mutually exclusive:operationcarries the label,operationTypedoes not. - Charging never fails your function. A billing error is logged and swallowed, and the call no-ops outside the logic function runtime so local runs and tests do not crash.
Checking before you spend
A workspace can run out of credits. When that happens your function is refused before your code starts, and the platform’s own work stops too:runAgent returns an error instead of running, and the other AI entry points refuse outright. sendInboxMessage runs no model and adds no AI charge of its own, though the function calling it is refused like any other; a member’s reply is charged like any chat turn. Uninstall and disconnect hooks are the exception and always run, so an app can still be removed cleanly. An execution that does get through can still fail late, on a platform call it did not write, if the workspace runs out mid-run.
Ask first:
reason comes with it: no-credits, no-subscription, or workspace-suspended. no-credits also covers an All usage limit an admin set on your app under Settings → Billing → Limits: the workspace may still have credits, but your app may not spend them.
Notes:
- It answers whether your app may spend in this workspace, not how much it has left. Your app does not see the balance, the plan or its limits.
- It fails open. If the check times out or the server is unreachable it reports credits available, so an infrastructure hiccup does not stop your app. Treat it as a hint worth honouring, not as an authorization decision.
- It is a snapshot. Credits can run out between the check and the work — including because of your own charges, since every charge you make moves the same counter this reads.
- The gate is not applied uniformly. Not every outbound email path is credit-gated, so a
falsehere tells you your app should not spend right now rather than predicting exactly which calls will fail.
Telling people what it costs
Declaring charges tells the platform how to meter your app; it does not tell a buyer what they will pay. Setbilling.description for that — one short, friendly line shown on your marketplace listing, before anyone installs.
src/application-config.ts
operations or recurring also asks the installing admin for consent: the install screen lists “Bill credits to your workspace”, and the app page shows “Bills credits”, with your description on hover.
Attribution
Spend is attributed to whoever triggered the run, so it shows up in Usage by User. Runs with nobody behind them (a webhook, a cron) have no triggering person — passuserWorkspaceId if your app knows who the spend belongs to. It must belong to the workspace the app is installed in, and it is ignored when the run does have a triggering user.
context.userWorkspaceId on a triggered run, or listConnections(), which returns the userWorkspaceId of each connection’s owner.
Recurring charges have no triggering person, so they are reported against the app only, never against a member.