Backendless
DEVELOPER · DEVELOPER
Data objects, their relations, and table permissions in the app they connected.
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.
backendless_delete_data_by_table_name_by_object_idWRITEDelete an object via DELETE /data/{table_name}/{object_id}. Permanently remove one object from a Data table by its objectId. The reply carries `deletionTime`, a timestamp in milliseconds. There is no undo: the object and its column values are gone, and any relation pointing at it is cleared. Runs as this Backendless application's RestUser role -- the role a REST API Key is auto-assigned -- not as any end user. Backendless also accepts an end-user `user-token` header here; Agentic Fabriq does not send one, because a session token in a tool argument is credential material. A 403 or an empty result here is a ROLE permission set in Backendless Console, not a bad key.
backendless_get_data_by_table_nameREADFind objects in a table via GET /data/{table_name}. List objects from a Data table, one page at a time. `pageSize` is the number of objects to return (1-100, default 10) and `offset` is how many to skip, so a full sweep advances `offset` by `pageSize` until a short page comes back. Runs as this Backendless application's RestUser role -- the role a REST API Key is auto-assigned -- not as any end user. Backendless also accepts an end-user `user-token` header here; Agentic Fabriq does not send one, because a session token in a tool argument is credential material. A 403 or an empty result here is a ROLE permission set in Backendless Console, not a bad key.
backendless_get_data_by_table_name_by_parentobjectid_by_relationnameREADFind an object's related objects via GET /data/{table_name}/{parentObjectId}/{relationName}. List the objects related to one parent object through a named relation column, one page at a time. `parentObjectId` is the parent's objectId and `relationName` is the relation column on the parent's table; `pageSize` and `offset` page through the related objects. Runs as this Backendless application's RestUser role -- the role a REST API Key is auto-assigned -- not as any end user. Backendless also accepts an end-user `user-token` header here; Agentic Fabriq does not send one, because a session token in a tool argument is credential material. A 403 or an empty result here is a ROLE permission set in Backendless Console, not a bad key.
backendless_post_data_by_table_nameWRITESave an object via POST /data/{table_name}. Save an object into a Data table. The body is the object itself -- any properties the table accepts -- and Backendless creates the table's columns on first use in a dynamic schema. The reply adds `objectId`, which identifies the object for every later read, update or delete, and `ownerId`. Runs as this Backendless application's RestUser role -- the role a REST API Key is auto-assigned -- not as any end user. Backendless also accepts an end-user `user-token` header here; Agentic Fabriq does not send one, because a session token in a tool argument is credential material. A 403 or an empty result here is a ROLE permission set in Backendless Console, not a bad key.
backendless_post_users_loginWRITELog an end user in via POST /users/login. Authenticate one of this application's END USERS with their login and password. `login` must be the value of the column marked as identity (email, in a default schema). The reply is the user object plus a `user-token` session token. CREDENTIAL MATERIAL IN THE ARGUMENTS: this call carries an end user's secret (a password, or a login provider's access token) in its body, and every tool call -- arguments included -- is recorded in Agentic Fabriq's audit trail. Use it only for end users of this Backendless application; it is not how this connection authenticates.
backendless_post_users_oauth_by_providercode_loginWRITELog an end user in with a social provider via POST /users/oauth/{providerCode}/login. Exchange a login provider's access token for a Backendless user, creating the user on first sight. `providerCode` is the provider's code as configured in this application's Console under Users > Login Providers (facebook, googleplus, github, linkedin, ...). This is Backendless acting as the OAuth CLIENT of that provider on behalf of this application's end users; it is not a way to connect Agentic Fabriq to Backendless. CREDENTIAL MATERIAL IN THE ARGUMENTS: this call carries an end user's secret (a password, or a login provider's access token) in its body, and every tool call -- arguments included -- is recorded in Agentic Fabriq's audit trail. Use it only for end users of this Backendless application; it is not how this connection authenticates.
backendless_post_users_oauth_by_providercode_request_urlREADGet a social-login authorization URL via POST /users/oauth/{providerCode}/request_url. Ask Backendless for the URL an end user should be sent to in order to authenticate with a configured login provider. `providerCode` is the provider's code from Console > Users > Login Providers. Send `redirect: false` with `contentType: application/json` to get the URL back as JSON; omitting `redirect` makes Backendless answer with an HTTP redirect instead.
backendless_post_users_registerWRITERegister an end user via POST /users/register. Create a user in this Backendless application's Users table. The body carries the new user's properties; `password` is required and `email` is the identity column in a default schema. `objectId` is used only to convert an existing GUEST user account into a registered one. CREDENTIAL MATERIAL IN THE ARGUMENTS: this call carries an end user's secret (a password, or a login provider's access token) in its body, and every tool call -- arguments included -- is recorded in Agentic Fabriq's audit trail. Use it only for end users of this Backendless application; it is not how this connection authenticates. Backendless echoes the submitted user object back on success, `password` included. Agentic Fabriq REMOVES that field from the reply and puts `[redacted by Agentic Fabriq]` in its place, so the password does not reach the model's context or the audit trail; nothing else in the object is touched. You supplied the value, so nothing is lost -- and the password is still in this call's ARGUMENTS, which the audit trail does record.
backendless_put_data_by_table_name_permissions_by_objectid_bulkWRITESet an object's ACL for several users via PUT /data/{table_name}/permissions/{objectId}/bulk. Replace the access-control list of ONE object for several users at once. The body is an ARRAY of entries, each naming a `userId`, a `permission` and a `permissionType` of GRANT or DENY. This changes who can reach that object for every caller of this Backendless application. Changes shared security configuration of the Backendless application. It takes effect for every client of that application, including its mobile and web SDKs, not only for this connection.
backendless_put_data_by_table_name_permissions_by_permission_typeWRITESet table permissions via PUT /data/{table_name}/permissions/{permission_type}. GRANT or DENY a table-level permission for a role or a user. `permission_type` is GRANT or DENY; the body's `permission` names the operation being governed (ADD, UPDATE, FIND, REMOVE, DESCRIBE, PERMISSION, LOAD_RELATIONS, ADD_RELATION, DELETE_RELATION, UPSERT, or `*` for all of them) and `role` or `user` names who it applies to. This changes who can reach the whole TABLE, for every caller of this Backendless application -- not only this connection. Changes shared security configuration of the Backendless application. It takes effect for every client of that application, including its mobile and web SDKs, not only for this connection.
backendless_put_data_by_table_name_permissions_by_permission_type_by_objectidWRITESet an object's ACL for one grantee via PUT /data/{table_name}/permissions/{permission_type}/{objectId}. GRANT or DENY one permission on ONE object for a single grantee. `permission_type` is GRANT or DENY and `objectId` names the object. This changes who can reach that object for every caller of this Backendless application. Changes shared security configuration of the Backendless application. It takes effect for every client of that application, including its mobile and web SDKs, not only for this connection.
Often connected alongside
Put Backendless behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.