What it does

• Declares trigger, action and data node types from any module, with RegisterTriggerType, RegisterActionType, RegisterDataNodeType and their Unregister* counterparts.
• Queues registrations made before the automation module attaches and replays them, so load order does not matter.
• Lists the available node types with ListTriggerTypes, ListActionTypes and ListDataNodeTypes.
• Starts a procedure from code. InvokeProcedure starts it from its manual trigger. RunProcedure starts it from any trigger, as Run now in the builder does.
• Ships procedures as code with DeclareProcedure. The automation module creates the procedure once under a stable ID and never changes it after that.
• Keeps your module independent of the implementation, @antelopejs/dms-automation.

Install

Add the interface to the module that declares nodes:

pnpm add @antelopejs/interface-dms-automation

If your module works without automation, move the interface to optionalDependencies. With no implementation loaded, registrations wait for one to attach, and your module keeps working. If your module needs automation to run, keep the interface in dependencies. Use a wide consumer range, from the interface release you build against up to <1.0.0, so package managers can deduplicate it. The implementing module caps its own dependency below the next interface minor instead.

Quick start

Register each node in start() and unregister it in stop():

import { RegisterActionType, UnregisterActionType } from "@antelopejs/interface-dms-automation";

const NOTIFY_ID = "my-module.notify";

export function start(): void {
  RegisterActionType({
    id: NOTIFY_ID,
    name: "Send notification",
    description: "Send a notification to a user",
    icon: "i-lucide-bell",
    inputSchema: {
      type: "object",
      properties: { userId: { type: "string" }, message: { type: "string" } },
      required: ["userId", "message"],
    },
    outputSchema: { type: "object", properties: { delivered: { type: "boolean" } } },
    async execute(input: { userId: string; message: string }, ctx) {
      ctx.log("info", "notifying", input);
      return { delivered: true };
    },
  });
}

export function stop(): void {
  UnregisterActionType(NOTIFY_ID);
}

A trigger also declares a required cluster mode. A "singleton" trigger, such as a schedule, fires on the elected leader only. A "replicated" trigger, such as a webhook, fires on every instance. Namespace node IDs as <module>.<node>, and keep schemas flat, with one property per port.

Compatibility

The compatibility block of the module README lists the interface range that each @antelopejs/dms-automation release implements. The interface declares this peer dependency:

InvokeProcedure, RunProcedure, DeclareProcedure and the List*Types functions queue their call until an implementation attaches. With no implementation loaded, the returned promise stays pending. By default, each function queues at most 1,000 calls, and the next one rejects with ProviderQueueFullError. A queued call whose calling module stopped rejects with ModuleContextInvalidatedError when an implementation attaches. To branch on availability, check GetInterfaceInstances("@antelopejs/interface-dms-automation") from @antelopejs/interface-core.

Documentation

• Consumer reference covers node contracts, lifecycle, clustering, invocation and failures.
• Extending the automation module covers node kinds, required members and running a procedure from code.
• The automation module guide covers the rest of the module.

The package also ships the dms-automation-interface Claude Code skill in skills/, declared under antelopeJs.skills.

Contributing

This package lives in the AntelopeJS/dms-automation pnpm workspace, next to the module that implements it. Read CONTRIBUTING.md and the repository README for the development commands. Release this package before the module that implements it.

License

Apache-2.0