create_database needs a workspace ID, and list_databases returns the databases across every workspace your token reaches, each tagged with the workspace it belongs to.
How the assistant works with your data
A few things shape the results you get. It reads the schema first.get_schema returns the authoritative reference for field types, their options, and the operators available for filtering. A well-behaved assistant calls it before creating tables or fields and before building a filter, rather than guessing.
Field keys are IDs, not column names. A record comes back keyed by field ID, not by the label you see in the table. list_fields maps between the two, which is why the assistant may look up a table’s fields before it can talk about a record in your terms.
Some fields cannot be written to. Formula, lookup, rollup, and count fields are computed from other data. Created time, updated time, created by, updated by, autonumber, and record ID are managed by Softr. The assistant can read all of them but cannot set them, and cannot change a field’s type after it is created.
Deleting is possible, and permanent. Records, fields, tables, and whole databases can all be removed through the assistant. There is no undo and nothing to restore from afterwards, so the assistant is expected to confirm with you before it deletes anything. See Deleting data.
Schema
Databases
Tables and fields
Records
Analytics
aggregate_data returns totals rather than rows, which makes it the right tool behind questions like “revenue by month” or “how many open tickets per assignee”. It groups by at most two fields.
Deleting data
Deletes are permanent. Nothing is kept in a trash you can restore from, so the assistant should tell you exactly what it is about to remove and wait for your go-ahead. A few rules apply, and they exist so an assistant cannot quietly take more than you meant. Deleting something that still holds data takes a second, explicit attempt. A database with tables in it, or a table with records in it, is refused the first time: the response says how much is inside, and the assistant has to repeat the call with a force flag to go through with it. Empty ones are deleted straight away. The refusal is a speed bump rather than a guarantee — a well-behaved assistant relays the count and asks you before retrying, and a count of 4,000 records is your cue to check it is the right table. A database always keeps at least one table. Deleting a database’s only table is refused outright, and force does not override it — the same rule the builder applies. If you want the last table gone, what you actually want is the database gone, so ask for that instead and the table goes with it. A table always keeps its primary field. Every other field can be deleted. Deleting a field removes its values from every record, drops it from any view’s filters and sorts, and marks formulas that referenced it invalid. Two things are not tidied up for you when a field goes. Deleting a linked record field leaves the matching field on the other table in place, still pointing at a relationship that no longer exists — remove it separately if the relationship is going away for good. Lookups and rollups that read through the deleted field are also left as they were. Worth checking what depends on a field before you remove it. Batch record deletes are lenient about IDs.delete_records takes up to 100 record IDs. IDs that no longer exist are skipped rather than failing the whole batch, and the result tells you how many records were actually deleted, so “deleted 8 of 10” means two were already gone.
Limits
Asking for more than 200 records is not an error — you simply get 200. Reading a large table therefore takes several calls, which is another reason to prefer a filter or an aggregate over paging through everything.