AWS SQS trigger

The AWS SQS type (Events family) listens to an Amazon SQS queue and starts a workflow for each message received — or for the received batch depending on the processing mode.

Before you begin

• An AWS account with access to SQS.
• An SQS queue created.
• Your AWS credentials (Access Key ID and Secret Access Key), ideally referenced in a dictionary.
• The necessary permissions to read from the queue.

Keys and credentials

Do not enter AWS credentials in clear text in the configuration: use dictionary variables.

Parameters

Parameter	Type	Required	Default	Description
Name	String	✅	—	Trigger label in the lists.
Description	String	✅	—	Summary of the trigger's purpose, for reviews and maintenance.
Path (slug)	String	✅	—	Identifier of the public URL, generated from the name.
Tags	List	❌	—	Labels to filter and find the trigger in the lists.
App	String	❌	—	Business application to attach to the trigger for mapping — see Apps.
Processing mode	PROCESS_PER_LINE / PROCESS_WHOLE	✅	PROCESS_WHOLE	Run a workflow per received message — data is an object (one execution per message); Run a workflow with all received messages — data is an array (one execution for the batch).
Queue URL (queue.url)	String	✅	—	Full URL of the queue to consume.
Access Key ID	String	✅	—	AWS Access Key ID.
Secret Access Key	String (masked)	✅	—	AWS Secret Access Key. Reference it via a dictionary variable rather than pasting it in clear text.

Advanced options

Parameter	Type	Required	Default	Description
Maximum number of attempts	Number	❌	—	Maximum number of request attempts in case of retryable failure.
Maximum number of messages	Number	❌	—	Number of messages fetched per call (1 to 10).
Message visibility delay (in seconds)	Number	❌	—	Duration during which a message stays invisible after being read.
Message attributes	List	❌	—	Names of business attributes to request with the messages.
System message attributes	List	❌	—	Names of SQS system attributes to request.

Input

The trigger consumes the configured queue and receives the messages present in it.

{
  "data": { "orderId": "CMD-4821", "status": "new" }
}

Output

The workflow receives the message content in data:

Property	Description
data	Content of the message.

The exact format depends on the message sent in the queue.

Errors

• Repeated failures — after a failure, the message becomes visible again once the Message visibility delay has elapsed then is reprocessed.
• DLQ — after several attempts, consider moving the message to a DLQ (Dead Letter Queue).
• Automatic deletion — Ecosystem deletes the message from the queue after a successful processing. On failure, the message stays in the queue and will be reprocessed.

Limits

• Message visibility delay — configure it at least equal to the duration of your workflow to avoid redelivery while processing.
• Costs — SQS charges for API requests, message storage and data transfer. Enable long polling and quickly delete the processed messages to reduce costs.

Example

1. In AWS: create an SQS queue and note its URL.
2. In Ecosystem: get your AWS credentials (Access Key ID and Secret Access Key), ideally referenced in a dictionary.
3. Create the trigger: AWS SQS type, fill in the queue URL, the Access Key ID and the Secret Access Key. Configure a Message visibility delay at least equal to the duration of your workflow.
4. Associate a workflow that receives the message, processes the order and deletes the message from the queue after success.
5. Deploy to production: the trigger consumes the queue.

See also

• Send AWS SQS node — sending and deleting messages in workflows
• Trigger node
• Create a trigger
• Deploy a trigger
• Other trigger types