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

Register a brand-new Anythink platform account with email and password. Use this only when the user has no account yet; if they already have one, use 'login' instead. This creates the top-level user identity — it does not create a billing account or project (do that with 'accounts_create' and 'projects_create' after logging in). On success the user may need to click an email confirmation link before 'login' works; tell them to confirm, then call 'login'.

Delete a user by ID. Removes the user from this project, so they can no longer sign in to it or use their role's access. The role and its permissions stay in place for everyone else. Make sure you have the right person with `users_get` first. It changes or deletes existing data, so check with the user before running it.

Get a user by ID. Shows one user's name, email, role, whether they have confirmed their invitation and when they were created. Use it to check one person's role; use `users_list` to scan everyone, and `roles_permissions_list` to see what their role allows.

Create a user and send an invitation email. Adds the person to this project with the role given by role_id, then emails them an invitation to confirm their account. Always pass role_id from `roles_list`: the API rejects an invite without an existing role, and administrator roles can't be given this way. Check `users_list` first so nobody is invited twice.

List all users. Shows each person who can sign in to this project with their id, name, email, role and whether they have confirmed their invitation. Use it to find a user's id, or to see who holds a role before changing it with `roles_permissions_add` or deleting it with `roles_delete`.

Show the currently authenticated user. Shows the user you are signed in as in this project: id, name, email, role, whether confirmed and when created. Your role decides what every other tool may do, so check it when a call is refused; use `users_get` to look up someone else.

Create a new workflow. Creates the workflow with one trigger and no steps: Manual needs entity, Timed needs cron, Event needs entity plus an event (EntityCreated by default) and an optional filter, and Api needs api_route. It stays disabled unless enabled is set; add steps with `workflows_step_add`, then turn it on with `workflows_enable`.

Delete a workflow. Removes the workflow with its triggers and steps, so it stops running and can't be restored. To stop it for a while use `workflows_disable`; to keep a copy first, use `workflows_export`. It changes or deletes existing data, so check with the user before running it.

Disable a workflow. Stops the workflow running from its triggers but keeps its triggers, steps and job history, so `workflows_enable` turns it back on. Prefer this to `workflows_delete` when a workflow should only stop for a while.

Enable a workflow. An enabled workflow runs on its own from its triggers: Timed on its cron schedule, Event when the matching event happens, Api when its route is called. Use `workflows_disable` to pause it without losing its steps.

Export an existing workflow to JSON (round-trippable with seed). Gives the workflow's definition as JSON with no ids: its triggers, and its steps with their parameters, linked by step key through on_success/on_failure. Use it to back up or copy a workflow; for the ids the step tools need, use `workflows_get`. It changes or deletes existing data, so check with the user before running it.

Add a FileHandler step with named flags (no hand-written params JSON). The step attaches a file to a record's file field: fetch_and_link downloads source_url, link_existing attaches existing_file_id, and detach unlinks it; entity, record_id (usually {{ $anythink.trigger.id }}) and field are always needed. Unlike `workflows_step_add` it can set on_success/on_failure in the same call, and the step is created disabled unless enabled is set.

Print a copy-paste-ready FileHandler params JSON. The sample uses {{ $anythink... }} templates for the source URL, record id and folder, and changes nothing in the project. Adapt it as params for `workflows_step_add` or `workflows_step_update`; to add a FileHandler step directly, `workflows_file_handler_add` is simpler.

Get workflow details and steps. Includes each trigger with its last and next run, and every step with its id, key, action, parameters, start-step flag and on_success/on_failure step ids. Use those step ids with `workflows_step_update`, `workflows_step_link` and `workflows_step_delete`; for a copy without ids, use `workflows_export`. Returns JSON.

Add an Integration step (Claude, OpenAI, Slack…) with named flags (no hand-written params JSON). The step runs one provider operation, such as claude generate-text, with inputs given as key=value pairs that accept {{ $anythink... }} templates; find provider and operation keys with `integrations_get`. credential_source chooses the credentials (system, current_user, connection with connection_id, or entity_field), and the step is created disabled unless enabled is set.

View job history for a workflow. Shows the 10 most recent runs, each with its status (Completed, Failed or Running), start time and error, plus every step's status, error and log. Use it after `workflows_trigger`, or when an event or schedule should have fired, to see whether a run worked and which step failed.

List all workflows. Each entry gives the workflow's id, name, description, enabled flag, step count and its triggers (Manual, Timed, Event or Api) with their config, but not the steps. Use `workflows_get` to see a workflow's steps and how they link. Returns JSON.

Create a workflow and its steps from a JSON file. Reads a JSON file on this machine in the `workflows_export` format (name, trigger or triggers, and steps with key, action, parameters and on_success/on_failure by step key), fills {{KEY}} placeholders from var, then creates the workflow, adds its steps and links them. It always creates a new workflow, so running it twice makes two copies.

Add a step to a workflow. Params are the action's settings as JSON, e.g. {"script":"return {}"} for RunScript or {"entity":"orders","data":{...}} for CreateData. The new step is unlinked: set start on the workflow's first step and chain the rest with `workflows_step_link`. For FileHandler or Integration steps, `workflows_file_handler_add` and `workflows_integration_add` build the params for you.

Delete a step from a workflow (warns if other steps link to it). The API refuses to delete a step that other steps still point to through on_success or on_failure, so re-point those with `workflows_step_link` first. Deleting the start step leaves the workflow with no entry point until a new step is added with start. It changes or deletes existing data, so check with the user before running it.

View step details including parameters. Shows one step's key, action, enabled and start-step flags, on_success/on_failure step ids and its full parameters. Read it before `workflows_step_update`, because params passed there replace the step's parameters as a whole.

Link workflow steps together (set on-success/on-failure). Sets which step runs next when this one succeeds (on_success) or fails (on_failure), by step id from `workflows_get`; a link you leave out keeps its current value. Links can be changed but not cleared here, and the step's name, action and params stay as they are. It changes or deletes existing data, so check with the user before running it.

Update step parameters and properties. Changes a step's name, params or enabled flag and keeps its action, start flag and links; it can enable a step but not disable one. Params replace the step's parameters as a whole, so read them with `workflows_step_get` first; to change which step runs next, use `workflows_step_link`. It changes or deletes existing data, so check with the user before running it.

Manually trigger a workflow. Starts a run now and returns without the run's result; check the outcome with `workflows_jobs`. A Manual-trigger workflow needs entity (and entity_id for a specific record), and payload is a JSON object the steps read as $anythink.trigger.data.

Update a workflow's name or description. Only the name and description change; the triggers, steps, group and enabled state are sent back unchanged, and no tool here edits a trigger. It refuses to run while an existing trigger is incomplete (e.g. a Timed trigger with no cron), which must be fixed in the dashboard first. To change a step, use `workflows_step_update`. It changes or deletes existing data, so check with the user before running it.