<!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/0-13-0/understanding-iii/functions.mdx. -->
Scanned 9/3/2026
Install to Claude Code
npx -y skills add iii-hq/iii --skill understanding-iii --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Understanding Iii?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/iii-hq-understanding-iii-cd7c74fc)More formats (shields.io, HTML) on the badges page.
<!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/0-13-0/understanding-iii/functions.mdx. -->
# Functions
## What a Function is
A Function is a named handler inside a Worker. It takes a payload and returns a result. From the iii
system's perspective, a Function is identified by its name and addressable across language and
location boundaries. Callers do not know what Worker is providing the Function, what language the
handler is written in, or where the Worker is running. The Engine routes each invocation to a Worker
that currently provides the target Function.
A Function has no fixed shape beyond payload-in / result-out. Some Functions are pure computation.
Some perform side effects (state writes, HTTP calls, queue enqueues). Some are agentic, invoking
other Functions in turn. The Engine does not distinguish: routing is the same for all of them.
## Function identifiers
Function identifiers use the `service::name` convention. The `service` segment groups related
Functions together as a namespace, scope, or worker name. The `name` segment is the specific
handler. Identifiers like `math::add`, `state::get`, and `http::serve` follow this convention.
The convention is a recommendation, not a hard rule. Any string is a valid function ID at the engine
level, but the `service::name` form makes the Function's intent obvious to readers and avoids
collisions between unrelated Functions registered by different Workers.
{/* TODO: Confirm if we still have restricted string prefixes */}
## Direct invocation
Registering a Function with `registerFunction()` makes it directly invokable through
`worker.trigger()` from any connected Worker and through the `iii trigger` CLI command. No explicit
Trigger registration is required for these two paths; they are the baseline call surface every
registered Function gets. Other trigger sources (HTTP, cron, queue, state, stream) bind an explicit
Trigger to the same `function_id`.
## Multiple Triggers per Function
A single Function can be the target of any number of Triggers. The same Function can be invoked by
an HTTP request, a cron schedule, and a queue message at once, by registering three separate
Triggers that share the same `function_id`. The function code does not change; only the trigger
registrations differ. This is what lets a single business-logic Function answer to many event
sources without per-source variants.

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!