Plans, limits & alerts

Plans

The MCP server and the REST API are on every plan, including Free. Limits are enforced when you cross them, not by disabling what you already made: reaching the project limit stops new projects, it does not lock the ones you have.

A live binding is one dataset that refreshes: a URL, REST, webhook or MCP connection. Uploaded files are not live bindings.

123

1. 1Current plan: and the renewal date when a subscription is active.
2. 2Usage: projects, datasets, storage, live bindings and seats, each against the plan limit.
3. 3Plans: monthly and yearly; checkout opens in an overlay and returns to this page.

Billing

Payments are handled by Paddle as merchant of record: they take the payment, charge and remit VAT/sales tax, and appear on the statement. Changing plan is immediate and prorated; cancelling keeps the plan until the end of the paid period and then drops the workspace to Free without deleting anything.

Refunds are covered on the refund policy page.

Going from a paid plan back to Free does not delete projects or datasets over the limit. They stay readable, and creating new ones is blocked until you are back under the limit. Surfaces published while on a paid plan keep the badge setting they had.

The agent budget

Independently of the plan, every workspace bounds what tokens and agents can pull. The values live on the workspace record and are reported by GET /api/v1/me and by the MCP mcp.usage query:

Per-connection query policy applies on top; the tighter of the two wins. Published surfaces read at up to 600 requests per minute per public id.

Alerts

An alert watches one metric and e-mails when it crosses a threshold. Rules are evaluated after every refresh of the underlying source, so an alert on a live feed fires within one refresh interval.

1234

1. 1Alerts: workspace-wide, across every project.
2. 2Rule: metric, comparison and threshold, in the rule's own words.
3. 3Recipients and cooldown: who gets it and how often at most.
4. 4State: enabled, last evaluated, last fired.

{
  metricId: "<metricId>",
  name: "M5+ inside the AOI",
  op: "gt",                 // gt · gte · lt · lte · eq · ne
  threshold: 0,
  cooldownSec: 21600,       // 6 hours; 60 s minimum, 7 days maximum
  recipients: ["ops@example.com"],   // 1 to 20 addresses
  params: {                 // optional scope, same shape as a metric query
    bbox: [25, 35, 45, 43],
    where: { mag: { gte: 5 } },
    aoi: { /* GeoJSON polygon */ },
    time: { from: "…", to: "…" }
  },
  enabled: true
}

• Cooldown is what keeps a flapping value from sending fifty mails: after a rule fires it stays quiet for cooldownSec.
• Test sends the rule through a real evaluation and shows the value it saw; with send on it also delivers the e-mail, so you can prove the address works before you need it.
• A rule on a static dataset never fires on its own, because nothing re-evaluates it. The alerts page marks which metrics are live.

E-mail delivery needs EMAIL_HOST, EMAIL_PORT, EMAIL_USER, EMAIL_PASSWORD and DEFAULT_FROM_EMAIL on the server. Without them rules still evaluate and record, but no mail goes out.

API tokens

1234

1. 1Settings tabs: General, Members, API tokens, Billing, Danger zone.
2. 2Ready-made snippets: the REST call and the MCP client entry for this deployment, with your origin filled in.
3. 3Create token: name it and pick scopes. The secret is shown once, at creation, and never again.
4. 4Tokens: prefix, scopes, creator, last use. Revoke takes effect immediately.

Tokens are workspace-bound and carry scopes read, write and publish. See REST API and MCP server.

What counts against what

Deleting a project keeps its datasets in the library, because datasets are workspace-level and shared. Delete them from Data if you want the storage back.