Softr

Delete a specific database by its ID. It can only be deleted if it is empty, unless the 'force' parameter is used. via DELETE /databases/{databaseId} DESTRUCTIVE, and `force` decides how destructive. Without it Softr refuses a resource that still has contents and answers 400; with `force=true` it deletes the resource AND everything inside it. There is no undo and no recycle bin in this API.

Delete a specific table by its ID. It can only be deleted if it is empty, unless the 'force' parameter is used. via DELETE /databases/{databaseId}/tables/{tableId} DESTRUCTIVE, and `force` decides how destructive. Without it Softr refuses a resource that still has contents and answers 400; with `force=true` it deletes the resource AND everything inside it. There is no undo and no recycle bin in this API.

Delete a specific field from a table. via DELETE /databases/{databaseId}/tables/{tableId}/fields/{fieldId} DESTRUCTIVE and permanent: Softr's API offers no undo and no recycle bin for what this removes.

Delete a specific record by its ID. via DELETE /databases/{databaseId}/tables/{tableId}/records/{recordId} DESTRUCTIVE and permanent: Softr's API offers no undo and no recycle bin for what this removes.

Delete a user from the specified Softr app via DELETE /v1/api/users/{email}. PERMANENT: the user record is removed and this API offers no way to restore it. Deactivate instead if you only need to stop them signing in -- that is reversible and keeps the record. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Retrieve a list of all databases accessible to the authenticated user. via GET /databases Every Softr resource is identified by a UUID: list the databases to get a databaseId, list that database's tables for a tableId, and read the table's fields or records for a fieldId or recordId.

Retrieve details of a specific database by its ID. via GET /databases/{databaseId} Every Softr resource is identified by a UUID: list the databases to get a databaseId, list that database's tables for a tableId, and read the table's fields or records for a fieldId or recordId.

Retrieve a list of all tables in the specified database. via GET /databases/{databaseId}/tables Every Softr resource is identified by a UUID: list the databases to get a databaseId, list that database's tables for a tableId, and read the table's fields or records for a fieldId or recordId.

Retrieve details of a specific table by its ID. via GET /databases/{databaseId}/tables/{tableId} Every Softr resource is identified by a UUID: list the databases to get a databaseId, list that database's tables for a tableId, and read the table's fields or records for a fieldId or recordId.

Retrieve details of a specific field. via GET /databases/{databaseId}/tables/{tableId}/fields/{fieldId}

Retrieve a list of all records in the specified table. via GET /databases/{databaseId}/tables/{tableId}/records Offset paging: `offset` skips records and `limit` sets the page size (the sealed API specification defaults it to 10; the reference page's pagination table says the default is 20 and the maximum 200). The reply's `metadata.total` is the total count -- keep paging while `offset < metadata.total`. Record values live in a `fields` object keyed by field ID (a UUID). Pass `fieldNames=true` to key it by the human-readable field name instead, which is usually what an agent wants.

Retrieve details of a specific record by its ID. via GET /databases/{databaseId}/tables/{tableId}/records/{recordId} Record values live in a `fields` object keyed by field ID (a UUID). Pass `fieldNames=true` to key it by the human-readable field name instead, which is usually what an agent wants.

Retrieve a list of views for a specific table. via GET /databases/{databaseId}/tables/{tableId}/views

Partially update a specific record by its ID. Only the fields provided in the request body will be changed. via PATCH /databases/{databaseId}/tables/{tableId}/records/{recordId} Record values live in a `fields` object keyed by field ID (a UUID). Pass `fieldNames=true` to key it by the human-readable field name instead, which is usually what an agent wants.

Create a new database in the specified workspace. via POST /databases

Create a new table in the specified database. via POST /databases/{databaseId}/tables Some field types are computed or system-managed (FORMULA, ROLLUP, LOOKUP, AUTONUMBER, RECORD_ID, CREATED_AT, UPDATED_AT, CREATED_BY, UPDATED_BY) and are read-only; the writable types are SINGLE_LINE_TEXT, LONG_TEXT, CHECKBOX, CURRENCY, DATE, DATETIME, DURATION, EMAIL, SELECT, NUMBER, ATTACHMENT, RATING, LINKED_RECORD, URL, PERCENT, PHONE and USER. Each type takes its own `options` object.

Add a new field to a table. via POST /databases/{databaseId}/tables/{tableId}/fields Some field types are computed or system-managed (FORMULA, ROLLUP, LOOKUP, AUTONUMBER, RECORD_ID, CREATED_AT, UPDATED_AT, CREATED_BY, UPDATED_BY) and are read-only; the writable types are SINGLE_LINE_TEXT, LONG_TEXT, CHECKBOX, CURRENCY, DATE, DATETIME, DURATION, EMAIL, SELECT, NUMBER, ATTACHMENT, RATING, LINKED_RECORD, URL, PERCENT, PHONE and USER. Each type takes its own `options` object.

Create a new record in the specified table. via POST /databases/{databaseId}/tables/{tableId}/records Record values live in a `fields` object keyed by field ID (a UUID). Pass `fieldNames=true` to key it by the human-readable field name instead, which is usually what an agent wants.

Search for records in the specified table based on filter, sort, and pagination criteria. via POST /databases/{databaseId}/tables/{tableId}/records/search Offset paging: `offset` skips records and `limit` sets the page size (the sealed API specification defaults it to 10; the reference page's pagination table says the default is 20 and the maximum 200). The reply's `metadata.total` is the total count -- keep paging while `offset < metadata.total`. Record values live in a `fields` object keyed by field ID (a UUID). Pass `fieldNames=true` to key it by the human-readable field name instead, which is usually what an agent wants.

Create a user inside the specified Softr app within your account via POST /v1/api/users. Supply the new user's full name and email; if you do not specify a password one will be generated for the user automatically, and `generate_magic_link` decides whether a Magic Link is generated for them. THIS GRANTS A REAL PERSON ACCESS to the customer's published app. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Re-activate a previously deactivated user in the specified Softr app via POST /v1/api/users/{email}/activate. The user can sign in again and counts toward the plan's user limit once more. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Deactivate a user in the specified Softr app via POST /v1/api/users/{email}/deactivate. The vendor: 'Deactivated users cannot log in and don't count toward your plan's user limit, but their record is retained and they can be re-activated later.' Flagged destructive because it locks a real person out of a live app; reversible with the matching activate tool. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Send an invitation email to an EXISTING user of the specified Softr app via POST /v1/api/users/{email}/invite. The vendor: 'Once invited, the user's status changes to Invited. Note that the app must be published for invitations to be sent.' THIS SENDS MAIL to a real address, so it is not a dry run. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Generate a Magic Link for the specified user in your Softr app via POST /v1/api/users/magic-link/generate/{email}. TREAT THE REPLY AS A CREDENTIAL: a Magic Link signs its holder into the app as that user without a password, so anyone who sees it is that user. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Sync a single user, an array of users, or -- with no emails supplied -- trigger a user sync for ALL users of the app, via POST /v1/api/users/sync. The vendor documents the body as a bare JSON ARRAY of email strings; sending no body at all is what makes it a sync of everyone, so an empty list here is sent as no body rather than as `[]`. This tool acts on the Softr APP named by this connection's Softr app domain setting, which is collected when the connection is made and sent as the `Softr-Domain` header -- it is never a tool argument. A connection made without it refuses every users tool by name rather than letting Softr answer an ambiguous 401. The app must be PUBLISHED. This API has no way to list users, so an email address has to come from somewhere else (the Softr users screen, or your own records).

Update the details of an existing database. via PUT /databases/{databaseId}

Update a table's name and/or description. To modify fields, use the field-specific endpoints. via PUT /databases/{databaseId}/tables/{tableId}

Update the properties of a specific field. via PUT /databases/{databaseId}/tables/{tableId}/fields/{fieldId} Some field types are computed or system-managed (FORMULA, ROLLUP, LOOKUP, AUTONUMBER, RECORD_ID, CREATED_AT, UPDATED_AT, CREATED_BY, UPDATED_BY) and are read-only; the writable types are SINGLE_LINE_TEXT, LONG_TEXT, CHECKBOX, CURRENCY, DATE, DATETIME, DURATION, EMAIL, SELECT, NUMBER, ATTACHMENT, RATING, LINKED_RECORD, URL, PERCENT, PHONE and USER. Each type takes its own `options` object.