Anythink all-in-one backend: data, auth, files, workflows, payments, APIs

Create a new billing account (organization) to hold projects and payment details. Requires a prior platform login (use the 'login' tool first). The new account is automatically set as the active account, so subsequent 'projects_create' / 'projects_list' calls target it without further setup. Returns the new account's id and name. Most users need only one account — call 'accounts_list' first to check whether a suitable one already exists.

List the billing accounts (organizations) the logged-in user belongs to. Requires a prior platform login (use the 'login' tool first). Returns each account's id, organization name, billing email, currency, and status (Active/Suspended/Canceled), and flags which one is currently active. A billing account holds your projects and payment details — pick one with 'accounts_use' before creating or listing projects.

Set the active billing account that project commands operate on. Call this after 'login' when you belong to more than one account, before using 'projects_list', 'projects_create', or 'projects_use'. Accepts a full account UUID or a unique prefix; run 'accounts_list' to see valid ids. Returns the resolved account name and id, or an error if no account matches.

List all API endpoints (platform + dynamically generated entity routes). Lists full URLs for a fixed set of core routes (auth, API keys, entities, fields, workflows), the five CRUD routes of every entity in the project plus public routes for public entities, and the route of each API-triggered workflow. Use it to give app developers endpoint URLs; to call one, use `fetch`. Returns JSON.

Create an API key. The raw key is shown once and never retrievable. Creates a project API key with the named permissions (names from `fetch` on /permissions) that expires after 1 to 365 days, 90 by default. Permissions you don't hold yourself are dropped with a warning. The raw key appears only in this output, or goes straight into a CLI profile with save_as, so store it at once. Returns JSON.

List API keys for the current user. Shows each key's id, name, number of permissions, expiry date and whether it is active, expired or revoked; key values are never returned. Use the id with `api_keys_revoke`.

Revoke an API key by ID. Revokes the key immediately and for good, so any script, CI job or CLI profile using it starts failing to authenticate. Create a replacement with `api_keys_create` first if something still needs access. It changes or deletes existing data, so check with the user before running it.

Create a chart. Check it first with charts preview. Saves a chart that plots an entity's records, a platform usage metric (see `charts_platform_metrics`) or a plan quota. Settings are checked first and the call is refused with the problems listed. The new chart isn't shown anywhere until you put it on a dashboard with `dashboards_add_chart` or `dashboards_create`. Returns JSON.

Delete a chart. Dashboards that show it keep an empty widget until you remove it. Permanently removes a saved chart from the project. To take a chart off one dashboard but keep it, use `dashboards_remove_widget` instead. After deleting, find the widgets that showed it with `dashboards_get` and clear them with `dashboards_remove_widget`. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Get a chart's full configuration. Shows every setting of one saved chart: type, data source, entity or metric, grouping, measure and aggregation, filters, time window, target and comparison. Read it before `charts_update`; to see the data it draws, use `dashboards_widget_preview` with type chart and its id. Returns JSON.

List charts, newest first. Shows each saved chart's id, name, type, data source, the entity or metric it plots and when it last changed; pass entity to see only one entity's charts. A chart is saved on its own and appears on a dashboard only once added with `dashboards_add_chart`. Returns JSON.

List the usage metrics a platform chart can plot. Shows each project usage metric a chart with source platform can plot: its id, label, shape, supported chart types and breakdowns. Pass a metric's id as platform_metric to `charts_preview` or `charts_create`, and one of its breakdowns as stack_by. Returns JSON.

Show the data a chart configuration would draw, without saving it. Runs a chart configuration against the project's current data and shows the points, totals or rows it would plot, trimmed to rows. Use it to settle entity, grouping, measure and filters before `charts_create` or `charts_update`; for a chart already saved, use `dashboards_widget_preview`. Returns JSON.

Change a chart. Only the settings you pass change; the rest stay as they were. Saves new settings on an existing chart; a filter replaces all of its existing filters. Dashboard widgets point at the chart rather than copying it, so every dashboard showing it draws the new version. Use `charts_get` first to see its current settings. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Run any Anythink CLI command and return its output. Prefer the dedicated tools; use this for anything they don't cover. Pass the command exactly as you would after 'anythink', e.g. 'entities list' or 'data list posts'. Destructive pay commands (delete, expire, relink, pause and similar) must be run by a person in a terminal; never add '--yes' on their behalf. 'data import' creates records (not destructive): run it with --dry-run first and only add '--yes' after the user approves the dry run. 'import directus' changes the project: run it with '--dry-run' first and only add '--yes' once the user has approved the plan. Add '--json' where supported for machine-readable output.

Delete a saved project profile from the local CLI configuration. Removes only the locally stored credentials and settings — it does not delete the project or revoke tokens server-side (to remove the project itself, use 'projects_delete'). Run 'config_show' to see profile names. Returns confirmation, or a not-found message.

Show the local CLI configuration: all saved project profiles and platform logins, and which of each is active. For every profile it returns the name, org id, auth method (api-key or token), alias, and platform; for every platform it returns the URLs, billing account, and login status. Use this to discover profile names for 'config_use', 'config_remove', or 'logout', and to check which project the 'cli' tool currently targets. Reads local config only — makes no network calls.

Switch the active project profile that the 'cli' tool's commands operate against. Use this to move between already-connected projects without re-authenticating. The profile must already exist (created by 'projects_use' or 'login_direct'); run 'config_show' to see available profile names. Returns confirmation, or an error if the profile does not exist.

Add a chart to a dashboard as a new widget. Everything else on the dashboard stays as it was. This is how a saved chart gets onto a dashboard. The widget takes the chart's name as its title unless title is given, and goes after the existing widgets unless column, row, width or height place it on the 12-column grid. Create the chart first with `charts_create`; avoid `dashboards_update` for this, as it replaces every widget. Returns JSON.

Create a dashboard, optionally with charts already on it. Makes a new dashboard owned by you, visible only to you unless shared is set. Each chart id passed becomes a chart widget titled with the chart's name; add more later with `dashboards_add_chart`. Build the charts first with `charts_create`. Making it the project default needs an administrator. Returns JSON.

Get the data behind a dashboard's widgets. Runs a saved dashboard's widgets, or only the widget ids passed, and shows each one's id, title, type and current data, trimmed to rows per widget. Use it to read what a dashboard shows now; use `dashboards_widget_preview` to try a widget that isn't on a dashboard yet. Returns JSON.

Delete a dashboard and its widgets. The charts on it are kept. Removes the dashboard for everyone who can see it. To take one chart off a dashboard, use `dashboards_remove_widget`; to delete a chart itself, use `charts_delete`. If it was your home dashboard, `dashboards_mine` falls back to the project default. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Get a dashboard with its widgets and their positions. Shows a dashboard's name, description, sharing settings, owner and each widget's id, type, title, the chart it shows and its grid position. Use it to find widget ids for `dashboards_remove_widget` and `dashboards_data`, and to see the current widgets before `dashboards_update`. Returns JSON.

List the dashboards you can see. Shows each dashboard's id, name, owner and whether it is your home, the project default or shared. A dashboard is a grid of widgets, most of them showing a saved chart; open one with `dashboards_get` to see its widgets, or `dashboards_mine` for the one you land on. Returns JSON.

Get your landing dashboard, or the project default if you have none. Shows the same detail as `dashboards_get` for the dashboard you see first when you open the project. Use it when you don't have a dashboard id; change which dashboard you land on with `dashboards_set_home`. Returns JSON.

Copy a dashboard over the project default that new users start from (administrators only). Overwrites the project default dashboard with a copy of this one. The default is what new users start from and what anyone without a home dashboard lands on; the dashboard you copy from stays as it was. To change only your own landing dashboard, use `dashboards_set_home`. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Remove a widget from a dashboard. Everything else on the dashboard stays as it was. Takes the widget off the dashboard and out of its layout; the chart it showed is kept and can be added back with `dashboards_add_chart`. Get widget ids from `dashboards_get`. Use `charts_delete` only to remove the chart from the project entirely. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Make a dashboard of yours your landing dashboard. Changes only your own landing dashboard, replacing your previous home; other users are unaffected. Check the result with `dashboards_mine`. To change what new users start from, use `dashboards_promote_to_default`. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Rename a dashboard, change who can see it, or replace its widgets and layout. Changes a dashboard's name, description or sharing, or replaces its whole widget list and layout through config; widgets missing from a new list are removed. To add or remove one chart, use `dashboards_add_chart` or `dashboards_remove_widget`, which keep everything else. Only the owner can change sharing. Returns JSON. It changes or deletes existing data, so check with the user before running it.

Show the data a widget would draw, without saving it. Works for a saved chart, given its id, and for list, materialised view, markdown and other widgets, given their config. Use it to see what a saved chart shows now, or to try a widget before adding it with `dashboards_add_chart` or `dashboards_update`; use `dashboards_data` for widgets already on a dashboard. Returns JSON.

Create a new record. Inserts one record from a JSON object of field names to values and returns the created record with its new id. Objects or arrays given for jsonb fields are sent as JSON strings automatically. Workflows with an EntityCreated trigger on this entity will run. To load many rows from a file, use `data_import`.

Delete a record. Removes one record by its numeric id. Records in other entities that point to it through a relationship field follow that field's on-delete rule; with the default, CASCADE, they are deleted too. Workflows with an EntityDeleted trigger on this entity will run. It changes or deletes existing data, so check with the user before running it.

Export records to a CSV, JSON or JSONL file (streamed page by page). Writes every matching record to a file on the machine running the CLI, or to standard output when the file is -, fetching page by page. Uses the same filter syntax as `data_list`; one-to-many fields are left out unless named in the field list. It won't overwrite an existing file unless forced. For one page of records, use `data_list`.

Get a single record by ID. Returns all of one record's field values by its numeric id. Use `data_list` with a filter when you don't know the id, `search_query` to find it by text, and `data_rls` to see which users can access it.

Create records from a CSV, JSON array or JSONL file. Always run with --dry-run first and only add --yes after the dry run is approved. Reads a file on the machine running the CLI and creates one new record per row, checking values against the entity's field types; rows with unknown columns are rejected unless told to ignore them. System columns such as id are ignored, so it never updates existing records. For a single record, use `data_create`.

List records in an entity. Returns one page of records (rows), 20 by default. Filter by field values with JSON such as {"status":"draft","price":{"gte":10}} or pairs such as status=draft&price=GTE:10. Use `data_get` when you know the record id, or `search_query` to find records by text across entities. Returns JSON.

View or set RLS (row-level security) user access on a record. Without a user id, returns the users who have row-level security (RLS) access to the record, with their names and whether access is read-only. With a user id, grants that user access to the record, full by default or read-only when asked. It cannot remove access, and only matters on entities with RLS turned on. It changes or deletes existing data, so check with the user before running it.

Update a record. Changes only the fields named in the JSON object and returns the updated record; other fields keep their values. Objects or arrays given for jsonb fields are sent as JSON strings automatically. Workflows with an EntityUpdated trigger on this entity will run. To create a record instead, use `data_create`. It changes or deletes existing data, so check with the user before running it.

Print the full CLI reference (markdown or --json for AI/tooling consumption). Prints a hand-written reference of CLI commands, options and examples without calling the API or needing a project. It omits some groups, such as integrations, secrets, API keys and settings, so treat the tool list as the authority on what exists. Returns JSON.

Render uncommitted subject + content + optional wrapper, print HTML. Renders a draft subject and body with sample data, inside a draft shell if given or the project's current one otherwise, and returns the HTML. Nothing is saved and no email is sent. Use it to check edits before `email_templates_update` or `email_shell_update`.

Show the current shell HTML (custom or platform default). Returns the HTML layout that wraps the body of every email the project sends, and says whether it is customised or the platform default. The {{Content}} placeholder marks where each template's body goes. Read it before `email_shell_update`.

Save new shell HTML, or pass --reset to revert to the platform default. Replaces the HTML layout around every email the project sends, or with reset returns to the platform default. Keep the {{Content}} placeholder where the body goes; the server sanitises the HTML. Check a draft with `email_preview` first. It changes or deletes existing data, so check with the user before running it.

List all email templates for this project. Shows each template's type (such as confirmation, invite or recovery), subject, and whether it is locked or active. These are the account emails Anythink sends for the project; pass a type to `email_templates_show` to read one or `email_templates_update` to change it.

Show a template's subject + content, or the rendered HTML with --rendered. By default returns the stored subject and content with their {{ placeholders }} intact, which is what to edit; with rendered it returns the full email HTML inside the project's shell, filled with sample data. Read it before `email_templates_update`.

Update a template's subject and/or content. Saves a new subject and/or body for one template type, keeping whichever you leave out; every email of that type the project sends from then on uses it. Pass the body inline in content_text. Check a draft first with `email_preview`, as the previous content isn't kept. It changes or deletes existing data, so check with the user before running it.

Create a new entity. Creates an empty entity, which is a new database table in the active project; add its columns afterwards with `fields_add`. Options make it public (queryable without signing in), turn on row-level security (RLS), block new records through the API, or mark it as a many-to-many junction table.

Delete an entity and all its data. Drops the entity's table, removing all of its fields and every record in it for good. To remove one column, use `fields_delete`; to remove one record, use `data_delete`. It changes or deletes existing data, so check with the user before running it.

Get entity details and fields. Takes the entity name. Returns its table name, its public, RLS and lock-new-records flags, and each field's id, name, database type, display type and required, unique and indexed flags. For one field's full definition, including relationship and select options, use `fields_get`.

List all entities. Returns each entity (table) in the active project with its database table name, field count, and whether it is public or has row-level security (RLS) on. System entities are not included. To see one entity's settings and field definitions, use `entities_get`.

Update entity settings. Changes an entity's public, row-level security (RLS) and lock-new-records settings; any you leave out keep their current value. It cannot rename the entity or change its fields, so use `fields_update` for columns. Making an entity public lets anyone query its records without signing in. It changes or deletes existing data, so check with the user before running it.