Loading

Plans and Usage Limits

Every self-serve app is on Starter or Pro, and each plan sets how big the app may grow: how many editors, datastores, records, how much file storage and how many API calls a day. Limits are checked when something new is created, never by deleting what is already there. This article lists them, explains what counts, and says what people see when a limit is reached.

Where to find it

Admin Panel → Account:

  • Billing & Plan — editors in use, and the Usage card with records, files and API calls against the plan

Architect Panel → Activity:

  • Usage Limit Notices — every 80% and 100% warning sent
  • API Calls per Day — calls counted per tenant per day

Architect Panel → Subscriptions:

  • Tenant Plans — the last counted records and storage for each tenant

The limits

  • Starter: 1 editor, 40 datastores, 50,000 records, 5 GB of file storage, 10,000 API calls a day.
  • Pro: 10 editors, 200 datastores, 1,000,000 records, 50 GB of file storage, 100,000 API calls a day.
  • Enterprise: no limits; arranged directly.

Each plan also includes a monthly AI credit; see AI Builder & Large Uploads for AI in self-serve apps.

What counts

  • An editor is a distinct person who is linked to the app as a tenant user, or who is in one of the app's groups with admin access. People in groups without admin access are free, however many there are. ActiveManage staff never count.
  • A datastore is one you have created; the platform's own built-in datastores do not count.
  • Records are counted across the app. Only adding new records is refused at the limit; existing records can still be viewed, edited and deleted.
  • File storage counts the files uploaded. At the limit new uploads are refused; existing files can still be opened and deleted. A single file bigger than the space left is refused on its own.
  • API calls count REST, MCP and A2A requests on the UK calendar day. Over the allowance, further calls are refused until midnight UK time.

What people see at a limit

  • Adding an editor: "Your Starter plan includes 1 editor and 1 is in use. Upgrade, or remove administrator access from someone first."
  • Creating a datastore: "Your Starter plan allows 40 datastores and this app already has 40. Upgrade to Pro, or delete a datastore you no longer need." The new datastore is not kept.
  • Adding a record or uploading a file at the limit: a message saying what is full, that existing items can still be used, and how to make room.
  • An API call over the allowance: a refusal saying when the allowance resets.

Warnings before the limit

For records and file storage, the app's administrators get an e-mail at 80% ("You've used 80% of your records") and at 100% ("Your app has reached its records limit"), and ActiveManage is told too. Each warning is sent once and re-arms when usage falls back below 75%. From 80%, Billing & Plan also shows a sentence under that line of the Usage card. Editors, datastores and API calls have no advance warning e-mail.

After a downgrade

A downgrade from Pro to Starter takes effect at the end of the paid period. An app that is still bigger than Starter at that point keeps everything, but:

  • the editors beyond the plan's allowance, newest first and never the billing owner, lose Site Administration (they can still use the app);
  • no new datastores, records or uploads can be added.

Billing & Plan explains this in a banner ending "Nothing has been deleted." It lifts as soon as the owner upgrades again or trims the app to fit. Starting a subscription on a plan smaller than the app is refused, with a message listing what is over the limit and "Choose Pro, or remove some first."

Freeing room

  1. Open Billing & Plan and read which limit is reached.
  2. For editors, remove admin access from somebody who does not need it, or move them to a group without admin access.
  3. For records or storage, delete what is no longer needed, or upgrade with Manage billing.
  4. Reload Billing & Plan and check the figures.

Worked example

A Starter app's owner invites a colleague as a second administrator and is refused with the editor message. They put the colleague in a group without admin access instead, which does not count as an editor, so the colleague can use the app but not Site Administration. Six months later records reach 80% and both administrators get the warning e-mail; they upgrade to Pro before the limit is reached.

Recommendations

  • Give admin access sparingly; ordinary users do not count as editors.
  • Act on the 80% e-mail rather than waiting for the limit.
  • Trim before downgrading, so nobody loses Site Administration.
  • Watch API calls if an integration polls the app frequently.