Skip to content
Agentic FabriqGet a demo
All integrations

Softr

DEVELOPER · DEVELOPER

Databases, tables, records, and app users in the Softr account they connected.

Connect Softr with Fabriq Developer

Your user pastes their Softr credential on a page Agentic Fabriq hosts, so it never reaches your backend and never becomes one shared key across all of your users. Same call as OAuth, one more argument.

from af_sdk import AgenticFabriq

af = AgenticFabriq()                      # reads AF_APP_ID / AF_APP_SECRET

url = await af.initiate_connection(request, provider="softr", method="api_key")
return redirect(url)                      # an AF-hosted page, not yours

async with await af.for_user(request) as session:
    tools = await session.get_tools()     # only what this user granted

Provider names are surfaces, not vendors, and the authoritative list is the capabilities endpoint rather than any page including this one — an unknown name returns 400 with the valid list. Fabriq Developer is free to start and needs no provider paperwork. Start free or read the quickstart.

Connecting Softr in practice

Softr has two unrelated APIs behind the same key name: the Database API at tables-api.softr.io, and the user-management API at studio-api.softr.io, which additionally requires a `Softr-Domain` header naming your published app. The Database API separates read from write in its rate limit — 40 requests/second for GET and POST /search against 30 for POST, PUT, PATCH and DELETE.

Scopes that draw scrutiny

  • Softr-Api-Key (Personal Access Token) Scoped to one or more workspaces and to scopes chosen at creation, but it "inherits permissions from the user who created it", so a token made by an owner is an owner-level token. Shown only once.
  • Softr-Domain Not a permission but a required header on the user endpoints, naming the app domain. A call without it fails even with a valid key.

Rate limits

  • 40 requests/second for GET and POST /search requests.
  • 30 requests/second for POST, PUT, PATCH and DELETE requests.
  • Over the limit returns 429 Too Many Requests, with the documented advice to back off and retry after a short delay.

Worth knowing

  • The user endpoints only work once the Softr app is published — an unpublished app returns errors that look like authentication failures.
  • Only workspace owners and collaborators can call the API: "guest collaborators of the application won’t be able to make calls."
  • Personal Access Tokens are the only option today; Softr says OAuth may be added later, so there is currently no way to connect on a user’s behalf without holding their token.
  • Delete endpoints for databases and tables refuse to run unless the object is empty, unless you pass the `force` parameter — so cleanup is a two-step decision.

Checked against Softr Database API authorisation (2026-09-29), Softr Database API rate limiting (2026-09-29), API setup and endpoints (2026-09-29)

Acts as the person, not as itself

Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.

Credentials never touch the agent

Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.

Every call on the record

Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.

What an agent can do

Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.

softr_delete_databases_by_databaseidWRITE

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.

api
softr_delete_databases_by_databaseid_tables_by_tableidWRITE

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.

api
softr_delete_databases_by_databaseid_tables_by_tableid_fields_by_fieldidWRITE

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.

api
softr_delete_databases_by_databaseid_tables_by_tableid_records_by_recordidWRITE

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.

api
softr_delete_users_by_emailWRITE

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).

api
softr_get_databasesREAD

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.

api
softr_get_databases_by_databaseidREAD

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.

api
softr_get_databases_by_databaseid_tablesREAD

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.

api
softr_get_databases_by_databaseid_tables_by_tableidREAD

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.

api
softr_get_databases_by_databaseid_tables_by_tableid_fields_by_fieldidREAD

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

api
softr_get_databases_by_databaseid_tables_by_tableid_recordsREAD

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.

api
softr_get_databases_by_databaseid_tables_by_tableid_records_by_recordidREAD

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.

api
softr_get_databases_by_databaseid_tables_by_tableid_viewsREAD

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

api
softr_patch_databases_by_databaseid_tables_by_tableid_records_by_recordidWRITE

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.

api
softr_post_databasesWRITE

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

api
softr_post_databases_by_databaseid_tablesWRITE

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.

api
softr_post_databases_by_databaseid_tables_by_tableid_fieldsWRITE

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.

api
softr_post_databases_by_databaseid_tables_by_tableid_recordsWRITE

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.

api
softr_post_databases_by_databaseid_tables_by_tableid_records_searchWRITE

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.

api
softr_post_usersWRITE

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).

api
softr_post_users_by_email_activateWRITE

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).

api
softr_post_users_by_email_deactivateWRITE

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).

api
softr_post_users_by_email_inviteWRITE

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).

api
softr_post_users_magic_link_generate_by_emailWRITE

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).

api
softr_post_users_syncWRITE

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).

api
softr_put_databases_by_databaseidWRITE

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

api
softr_put_databases_by_databaseid_tables_by_tableidWRITE

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

api
softr_put_databases_by_databaseid_tables_by_tableid_fields_by_fieldidWRITE

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.

api

Put Softr behind one governed endpoint.

Same permissions, same audit trail, whatever else you connect next.