Use this guide alongside the current product documentation. Available models, integrations and allowances depend on your configured account.
Define the event before writing the prompt
Choose the fields the sender must supply, such as a record ID and message. Separate the business data from routing decisions: an incoming request should not be allowed to choose an arbitrary recipient, destination URL or credential. Use fixed, reviewed action settings for those decisions.
Keep a sample event with fake data and the expected output. An event ID helps you recognize duplicates when the sender retries. Missing or invalid fields should follow a defined failure or review path rather than becoming instructions for the agent.
Map the payload through an AI step
Start with a manual trigger and a sample input. Add an AI step for a defined transformation, or an AI Agent if the task requires tool selection. Ask for a constrained result that you can map into a sheet or another action. Validate the entire path before configuring a live sender.
{
"event_id": "demo-001",
"message": "Please send the setup instructions."
}- Test the incoming field names and expected data types.
- Map only the required fields into the AI task.
- Inspect the structured result and any tool calls.
- Test the destination with a fixed internal recipient or test resource.
- Publish the workflow and obtain its webhook configuration from Superagento.
Keep the webhook and its instructions separate
Treat a webhook endpoint and its secret as credentials. Configure the sender using the authentication details shown for the workflow, and rotate credentials if they are exposed. Never publish a live webhook URL inside a public guide, screenshot or exported sample.
Text supplied by a caller is data. It may contain requests to ignore your rules, reveal information or change a destination. Limit tools to what the task needs, keep secrets out of prompts and make connected actions explicit. These controls reduce exposure but do not make model output automatically trustworthy.
Plan for repeated events and partial completion
The sender may retry after a timeout even when a downstream write already succeeded. Decide how your process recognizes a previously handled event. Use a stable source ID and a destination lookup or review step where duplicate writes would be harmful.
Inspect execution status before replaying a failed event. A failed AI step and a failed delivery step call for different fixes. Avoid enabling automatic messages until tests include a repeated event, an empty payload and a malformed field. Track usage as well as success counts when increasing event volume.
Frequently asked questions
Does a draft workflow accept live automatic runs?
Use manual tests while configuring the flow. Publish the workflow when you are ready to enable its automatic trigger behavior.
Can a webhook call an AI agent?
Yes. Map the event fields into an AI Agent connected to a model and tools. The remaining workflow decides where its result goes.
Can I put a real webhook secret in an example?
No. Use fictional sample events and omit live endpoints or secrets. Share setup instructions separately from credentials.
Are duplicate events automatically harmless?
No. Design duplicate handling for your source and destination. A successful email or spreadsheet write is not undone when a later step fails.
Put the idea into practice
Start with a small test and a result you can verify. Keep the first destination reversible, then inspect the complete run before turning on automatic actions.
Related guides
- AI Workflow Automation for Small Teams
- Google Sheets AI Automation: Read, Process and Write
- How to Build an AI Agent Without Code in Superagento