Short answer: Drop the "AWS SQS → Receive SQS Messages" action anywhere in your workflow, map the inputs from upstream nodes, and publish.
Every field can be mapped from an upstream trigger, AI step, table row, or hard-coded literal.
| Field | Type | Required | Description |
|---|---|---|---|
Queue URL queue_url | string | Required | A fully qualified URL (https://...) for the queue url. |
Max Messages max_messages | number | Optional | 1-10. |
Wait Time (s) wait_time_seconds | number | Optional | Long-poll timeout. 0-20. |
Visibility Timeout (s) visibility_timeout | number | Optional | Hide from other consumers while you process. Delete before this expires. |
{"queue_url": "e.g. https://example.com/path","max_messages": "{{trigger.max_messages}}","wait_time_seconds": "{{trigger.wait_time_seconds}}","visibility_timeout": "{{trigger.visibility_timeout}}"}
{"Messages": [{"Body": "{\"event\":\"order.created\"}","MD5OfBody": "...","MessageId": "abc","ReceiptHandle": "AQEBxyz..."}]}
Use these fields in downstream nodes for routing, logging, or error handling.
Any of these apps can fire this action as part of a workflow.
Triggered by anything in the catalog. Free tier available. No credit card.