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. 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
