Action types
Kwala supports three primary action types:- Deploy: Deploy new smart contracts to blockchain networks
- Call: Interact with existing smart contracts
- API: Invoke external Web2 APIs
Deploy actions
Deploy actions are used to deploy new smart contracts to a blockchain network. You can also use deploy actions to deploy Kwala Functions, which enable custom on-chain decision logic. In the following example, we deploy an NFT contract to Ethereum mainnet. The initialization parameters are contract name (“MyNFT”), symbol (“NFT”), and initial supply (1000 tokens).| Field | Description |
|---|---|
| name | Unique identifier for this action |
| type | Must be "deploy" |
| bytecode | The compiled contract bytecode (hex string) |
| encodedABI | ABI-encoded constructor parameters |
| initializationArgs | Array of constructor arguments |
| chainID | Target blockchain network ID |
| Field | Description | Default |
|---|---|---|
| metadata | Additional information about the deployment | - |
| retriesUntilSuccess | Number of retry attempts on failure | 0 |
Call actions
Call actions interact with already deployed smart contracts by calling their functions. The following example calls thetransfer function on an ERC-20 token contract to send 1 token to a recipient address:
| Field | Description |
|---|---|
| name | Unique identifier for this action |
| type | Must be "call" |
| targetContract | Address of the smart contract to interact with |
| targetFunction | Name of the function to call (For example, transfer, mint) |
| targetParams | Array of parameters for the function call |
| chainID | Target blockchain network ID |
| encodedABI | ABI-encoded function call |
| Field | Description | Default |
|---|---|---|
| metadata | Additional information about the call | - |
| retriesUntilSuccess | Number of retry attempts on failure | 0 |
API actions
API actions allow you to integrate Web2 services into your Web3 workflows. The following example action sends a Discord notification using a webhook to announce that a new NFT has been minted, including an embedded message with the token ID.| Field | Description |
|---|---|
| name | Unique identifier for this action |
| type | Must be "api" |
| APIEndpoint | Full URL of the API endpoint |
| APIPayload | Request body/parameters for the API call |
| Field | Description | Default |
|---|---|---|
| metadata | Additional information about the API call | - |
| retriesUntilSuccess | Number of retry attempts on failure | 0 |
Complete field reference
Here’s a comprehensive reference of all action fields:| Field | Required | Used In | Description |
|---|---|---|---|
| Name | Required | All | Unique name for this action |
| Type | Required | All | Type of action: deploy, call, or api |
| APIEndpoint | Required for api | API | URL if making an API call |
| APIPayload | Required for api | API | Request body for the API call |
| Bytecode | Required for deploy | Deploy | Contract bytecode (hex string) when deploying |
| EncodedABI | Required | Deploy, Call | ABI-encoded constructor or function call |
| InitializationArgs | Required for deploy | Deploy | Arguments to pass into the constructor |
| TargetContract | Required for call | Call | Address of the smart contract to interact with |
| TargetFunction | Required for call | Call | Function name such as transfer, mint, or others. |
| TargetParams | Required for call | Call | Parameters for the function call |
| ChainID | Required | Deploy, Call | EVM Chain ID where the action will be executed |
| Metadata | Optional | All | Optional metadata or tags |
| RetriesUntilSuccess | Optional | All | Number of retries until success (default is 0) |
Retry logic
TheretriesUntilSuccess field allows actions to automatically retry on failure.
The following example configures a critical contract call to automatically retry up to 5 times if it fails, ensuring higher reliability for important operations.
- Retries happen automatically on failure
- A delay is applied between retries
- Total attempts = 1 (initial) + retriesUntilSuccess
- Failed retries still consume credits
Best practices for workflow actions
- Use descriptive action names - Choose clear, descriptive names that explain what each action does. It’s easier to understand and debug a workflow called
Deploy NFT Marketplace Contractas opposed toAction1. - Validate parameters - Double-check all parameters, especially addresses and amounts, before deploying workflows
- Set appropriate retries - Use retries for critical operations, but avoid excessive retries that waste credits
- Network calls: 2-3 retries
- Contract deployments: 1-2 retries
- Simple reads: 0-1 retries
- Add metadata - Use the metadata field to document why an action exists and any important context
- Test in the Playground - Always test your actions in the Kwala Playground before deploying to production
Combining Web2 and Web3 actions
One of Kwala’s key features is the ability to combine Web2 and Web3 actions in a single workflow. The following example demonstrates a complete workflow that mints an NFT on-chain, sends an email notification to the user via SendGrid API, and logs the transaction to a database via a custom API endpoint.Next steps
Working with Triggers
Learn how to trigger your workflows
Workflow Execution
Understand workflow execution modes
YAML Basics
Master Kwala’s YAML syntax
Use Cases
Explore real-world examples
