Actions

An Action is a Workflow step that performs work in another app. FastHook reads each provider's Action manifest to render the correct authentication choices, fields, resource pickers, validation, output contract, and rate limit.

Add an Action

1. Open a Workflow and select an add point.
2. Choose Action.
3. Select a provider and operation.
4. Select or create the required provider account.
5. Configure the required target and input fields.
6. Map values from the Trigger or earlier Steps.
7. Save the Action step and produce a trigger event.

Authentication

An Action may support one or more modes, depending on the provider: a FastHook-managed bot, your own bot or app credential, OAuth, API key, or a customer webhook. The dialog only shows modes declared by that provider Action.

Grant the smallest provider scope that supports the selected operation. If a run returns a permission error, compare the Action's required scopes with the account that was actually selected.

Inputs

Action inputs fall into three practical groups:

• Target fields select where work happens, such as a channel, spreadsheet, repository, calendar, or record.
• Content fields contain the data to send or write and usually support mappings.
• Advanced fields control optional provider behavior and can normally remain at defaults for a first run.

Required fields are validated before the Action is saved. Provider errors can still occur at runtime if a resource was deleted, access changed, or a value violates a provider rule.

Outputs

Actions publish an output schema and example. Later Steps can map values from successful outputs through steps.<step-id>. A failed Action exposes a normalized failure envelope only on its error route; failed output is not treated as normal success data.

Action versus Destination

Choose an Action when FastHook should call a named provider operation such as “Send message” or “Create record.” Choose a Destination step when FastHook should deliver data through a reusable HTTP, CLI, or other transport configuration.

Rate limits and retries

Provider manifests declare an Action rate limit, and provider APIs may add their own limits. Temporary failures can be retried by the Workflow runtime. Design Actions to tolerate retries where the provider operation can create duplicate side effects.

Use Data mapping to configure inputs and Runs and errors to inspect the exact provider result.