New — Self-Automation

InTouch automates itself.
A scheduled script with the same rights as one of your users.

A runtime env tool carries an InTouch Publisher credential. When it fires, the server logs in as that publisher, hands the script a short-lived session token, and logs out automatically when the tool ends. The script calls the InTouch REST API as a real publisher — with that publisher's RBAC — and never sees the password.

Available on Every Edition How RBAC Makes This Safe
The Headline Properties

Four Things That Make This Work

Same rights as a user

The script's session belongs to a real publisher. Every API call is checked against that publisher's roles, project access, group memberships, and rights — the same RBAC that gates the UI.

Never sees the password

The credential's secret is read by the server, used to perform the in-process login, and discarded. The child process environment receives only the session token.

Bounded by tool lifetime

The session is created right before the script starts and logged out in a finally block. Success, failure, timeout, kill — all release the session immediately.

Fully audited

The credential's creator is server-stamped and immutable. Every API call from the script lands in the activity log, attributable to the named publisher.

The Unlock

Three InTouch Surfaces in One Script. No Password.

Read the activity log. Ask InTouch's own AI to triage failures. Mutate state. All under a real publisher with full RBAC and full audit. There is no equivalent of this on Zapier, Make, n8n, or Power Automate.

The script on the right is a real, runnable runtime env tool. Schedule it every 15 minutes. It reads the last day of activity, hands the failures to InTouch's own AI assistant for triage, then acts on the verdict — re-running flaky jobs, disabling jobs the AI flags as broken upstream.

Three things stack here that nobody else combines: the script reads InTouch's own activity log (RBAC-filtered), calls back into InTouch's own AI (with this publisher's tool access), and mutates InTouch's own state (every action server-stamped with creatorPublisherId). The platform is introspectable from within itself.

Swap one variable and you have staging→prod promotion: two intouch_publisher credentials (one per server), one wrapper script that walks every job in staging via /job/list and recreates the matching jobs on prod via /job/insert-base. Same 30-line pattern. No Kotlin. No CI/CD pipeline.

The platform manages itself. That is the unlock.

# self_heal.py — runtime env tool, scheduled every 15 min import os, json, urllib.request, urllib.parse BASE = f"http://{os.environ['INTOUCH_SERVER']}:{os.environ['INTOUCH_PORT']}/intouch" TOKEN = os.environ["SESSION_TOKEN"] def call(method, path, body=None, **params): params["sessionId"] = TOKEN url = f"{BASE}{path}?{urllib.parse.urlencode(params)}" data = json.dumps(body).encode() if body else None req = urllib.request.Request(url, method=method, data=data, headers={"Content-Type": "application/json"} if body else {}) with urllib.request.urlopen(req) as r: raw = r.read() return json.loads(raw) if raw else None # 1. READ — activity log, RBAC-filtered to this publisher failures = [w for w in call("GET", "/job-activity/get-work-completed-on-days-ago", daysAgo=1) if w["resultCode"] != 0] if not failures: exit(0) # 2. INFERENCE — InTouch's own AI assistant triages prompt = ("Triage these InTouch job failures. Reply with ONLY a JSON array of " "{jobId:int, action:'rerun'|'disable'|'ignore', reason:str}.\n" + json.dumps(failures, default=str)) verdict = json.loads(call("POST", "/assistant/ask", body={"question": prompt})["answer"]) # 3. WRITE — every action audited under creatorPublisherId for v in verdict: if v["action"] == "rerun": call("POST", "/job/run-jobs", jobIds=str(v["jobId"])) elif v["action"] == "disable": call("PUT", "/job/update-enabled-status", jobId=v["jobId"], enabled="false") print(f" {v['action']:7s} jobId={v['jobId']:<5} // {v['reason']}")
What This Unlocks

Self-Healing, Compliance, Cross-Server — All as Ordinary Jobs

Self-healing automation

A scheduled script that scans recent activity logs for failures, classifies them, and either restarts the failed jobs, alerts the right subscriber, or files a follow-up trigger. Pure InTouch logic — no new tools.

Compliance sweeps

Nightly scripts that diff actual server state against expected state, rotate credentials older than N days, ensure every production job has alert subscribers, generate audit reports.

Cross-instance sync

Two intouch_publisher credentials (one per server) and one Python script gives you staging→prod promotion, DR replication, or multi-region sync. No Kotlin required.

Fleet management

One script orchestrates a fleet of InTouch servers — deploy a new schedule everywhere, audit which server runs what, retire obsolete jobs in bulk. Each server keeps its own RBAC.

AI-authored automation

Describe the goal to the AI assistant. The assistant writes the script, creates the runtime env job, and wires the credential. The script is the artifact — readable, editable, version-controllable.

Domain-specific scripts

Each team writes scripts in its domain language — finance scripts for finance, ops scripts for ops. Every script operates within its publisher's RBAC, so the platform doesn't need to know anything about the domain.

The Mechanism

Six Lifecycle Steps, Server-Managed

  1. You create an intouch_publisher credential with the publisher's name and password.
  2. You create a runtime env tool pointing at your script and attach the credential.
  3. Server validates the credential type at insert/update time. Mismatched types are rejected with a clear error.
  4. Server logs in as the publisher (in-process — no REST round trip) before the script starts.
  5. Server injects four environment variables into the script process: SESSION_TOKEN, INTOUCH_SERVER, INTOUCH_PORT, INTOUCH_PUBLISHER. The password is not in the environment.
  6. Server logs out the session in a finally block when the tool ends. The token becomes invalid the moment the tool finishes — success, failure, timeout, or kill.
# Minimal self-automation script import os, urllib.request, urllib.parse, json base = f"http://{os.environ['INTOUCH_SERVER']}:{os.environ['INTOUCH_PORT']}/intouch" def get(path, **params): params["sessionId"] = os.environ["SESSION_TOKEN"] qs = urllib.parse.urlencode(params) with urllib.request.urlopen(f"{base}{path}?{qs}") as r: return json.load(r) print("Publisher:", os.environ["INTOUCH_PUBLISHER"]) print("Jobs:", len(get("/job/list"))) print("Credentials:", len(get("/credential/list"))) print("Schedules:", len(get("/schedule/list")))
Beyond intouch_publisher

Any Credential, Auto-Exported as Env Vars

Runtime env tasks can attach multiple credentials at once. Each credential's values are exported into the script's environment using a tool-type convention — no manual env var plumbing.

One convention, every credential type

  • An openai credential exports OPENAI_API_KEY.
  • An aws credential exports AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
  • A mysql credential exports MYSQL_HOST, MYSQL_PORT, MYSQL_USER, MYSQL_PASSWORD.
  • A github token exports GITHUB_TOKEN.

The pattern matches OpenClaw skills' requires.env conventions, so a skill that asks for OPENAI_API_KEY works as soon as you attach an openai credential. When a script wants non-standard names, the per-task Credential Env Var Overrides map adds aliases.

# Inline script + two credentials, no plumbing import os, openai, mysql.tool # Both come from attached credentials — no .env file, no secrets in code. client = openai.OpenAI(api_key=os.environ["OPENAI_API_KEY"]) db = mysql.tool.connect( host=os.environ["MYSQL_HOST"], port=int(os.environ["MYSQL_PORT"]), user=os.environ["MYSQL_USER"], password=os.environ["MYSQL_PASSWORD"], )
Password Rotation

One Rotation, Every Credential Re-Encrypts

When a publisher changes their password, every intouch_publisher credential whose login matches that publisher is automatically re-encrypted with the new value. Tools using those credentials keep working without manual sync.

The Programmable Surface InTouch Already Was — Now Wired To Itself.

Every InTouch REST endpoint your publishers can call interactively is now callable from a scheduled script under the same RBAC, with the same audit trail, with the same encrypted credential vault. Available on every edition, including Personal.

Get Personal Edition Let the Assistant Write It