Automation API

AutomationApi (com.n3plugins.sdk.workflow.AutomationApi) is a static facade over the high-level interaction surface. It groups the action APIs into 18 named sub-APIs reachable as static fields, so workflow-builder Services implementations and ad-hoc scripts share one entry point.

AutomationApi.combat.attackNPC(target);
AutomationApi.bank.withdraw(ItemID.NATURE_RUNE, 100, false);
AutomationApi.dialogue.continueDialogue();

This is the surface the combat and production builder Services delegate to (see combat-and-prayer.md, production-workflow.md). It does not replace the result-aware InteractionApi.actions.* classes - many sub-APIs return boolean or domain types. Use InteractionApi when you need the richer InteractionResult status.

Public methods and nested sub-API types under this facade must carry source Javadocs. ApiJavadocCoverageTest covers this file as part of the public sdk surface.

Sub-APIs

Field	Type	Covers
widgets	WidgetActions	get/search widgets, first-by-action/name/text, interact, use-on-widget, resume count/string/name
dialogue	DialogueActions	isPresent, snapshot, continueDialogue, select(index/text), resume helpers
inventory	InventoryActions	items, first, use(id/name, actions), use-on npc/object/ground-item/player
bank	BankActions	isOpen, items, count, withdraw(id, amount, noted), setWithdrawNoted, deposit inventory/equipment
npcs	NpcActions	nearestByPath(name), interact(npc/name, actions), useWidgetOn
objects	ObjectActions	nearestByPath(name), interact(object/name, actions), useWidgetOn
groundItems	GroundItemActions	nearest, interact, take, useWidgetOn
players	PlayerActions	nearest, interact(player/name, actions), useWidgetOn
prayers	PrayerActions	active-state checks, getPoints, enable/disable/set/setOnly/disableAll, quick-prayers, best offensive prayer per style (returns InteractionResult for writes)
combat	CombatActions	health/spec/in-combat reads, toggleSpec, setAttackStyle, getAttackableNPC, attackNPC
spells	SpellActions	resolve spell widget, cast(name), cast-on npc/object/ground-item/player
teleports	TeleportItemActions	use(id/name), useEquipped(id/name)
shops	ShopActions	isOpen, items, buy(id/name, quantity), use-inventory-item
grandExchange	GrandExchangeActions	isOpen, items, offer(id/name)
trade	TradeActions	trade/accept state, accept, offerAll, offerX
vars	VarActions	bit(varbitId), player(varPlayerId)
walker	WalkerActions	walkTo(WorldPoint), stop, isWalking, nearestBank, walkNearestBank
quests	QuestActions	quest helper destination, walkToDestination

Usage in a builder Services

The builder owns step ordering; the Services impl wires each callback to the matching sub-API:

CombatWorkflowBuilder.Services services = new CombatWorkflowBuilder.Services() {
    public NPC findTarget(Predicate<NPC> predicate) {
        return AutomationApi.combat.getAttackableNPC(predicate).orElse(null);
    }
    public void attack(NPC target) {
        AutomationApi.combat.attackNPC(target);
    }
    public void loot(int... ids) {
        for (int id : ids) AutomationApi.groundItems.take(itemName(id));
    }
    // ... remaining callbacks ...
};

When to use which surface

• AutomationApi - concise, grouped access for builder Services and scripts that act on success/failure as a boolean.
• InteractionApi.actions.* - when you need the InteractionResult status (e.g. to distinguish PACED / TARGET_NOT_FOUND from a real failure, or to bridge into a TaskPipeline via StepResult.fromInteraction).
• sdk.query.* - read-only scene/inventory/equipment queries with fluent filters (see query-helpers.md).

All write paths ultimately route through the same ActionPacer gate, so pacing is consistent regardless of which surface you call (see sdk-pipeline-guide.md §2).