SQS

Stream can send payloads of all events from your application to an Amazon SQS queue you own.

A chat application with a lot of users generates a lots of events. With a standard Webhook configuration, events are posted to your server and can overwhelm unprepared servers during high-use periods. While the server is out, it will not be able to receive Webhooks and will fail to process them. One way to avoid this issue is to use Stream Chat’s support for sending webhooks to Amazon SQS.

SQS removes the chance of losing data for Chat events by providing a large, scalable bucket that holds events generated by Stream Chat in a queue for your server or other .

The complete list of supported events is identical to those sent through webhooks and can be found on the Events page.

Configuration

You can configure your SQS queue programmatically using the REST API or an SDK with Server Side Authorization.

There are 2 ways to configure authentication on your SQS queue:

  1. By providing a key and secret

  2. Or by having Stream’s AWS account assume a role on your SQS queue. With this option you omit the key and secret, but instead you set up a resource-based policy to grant Stream SendMessage permission on your SQS queue. The following policy needs to be attached to your queue (replace the value of Resource with the fully qualified ARN of your queue):

{
  "Sid": "AllowStreamProdAccount",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::185583345998:root"
  },
  "Action": "SQS:SendMessage",
  "Resource": "arn:aws:sqs:us-west-2:1111111111:customer-sqs-for-stream"
}

To configure an SQS queue, use the event_hooks array and Update App Settings method:

// Note: Any previously existing hooks not included in event_hooks array will be deleted.
// Get current settings first to preserve your existing configuration.

// STEP 1: Get current app settings to preserve existing hooks
$response = $client->getAppSettings();
$existingHooks = $response['event_hooks'] ?? [];
echo "Current event hooks: " . json_encode($existingHooks);

// STEP 2: Add SQS hook while preserving existing hooks
$newSQSHook = [
    'enabled' => true,
    'hook_type' => 'sqs',
    'sqs_queue_url' => 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue',
    'sqs_region' => 'us-east-1',
    'sqs_auth_type' => 'keys', // or 'resource' for role-based auth
    'sqs_key' => 'yourkey',
    'sqs_secret' => 'yoursecret',
    'event_types' => [] // empty array = all events
];

// STEP 3: Update with complete array including existing hooks
$client->updateAppSettings([
    'event_hooks' => array_merge($existingHooks, [$newSQSHook])
]);

// Test the SQS connection
$client->checkSqs([
    'sqs_queue_url' => 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue',
    'sqs_key' => 'yourkey',
    'sqs_secret' => 'yoursecret'
]);

Configuration Options

The following options are available when configuring an SQS event hook:

OptionTypeDescriptionRequired
idstringUnique identifier for the event hookNo. If empty, it will generate an ID.
enabledbooleanBoolean flag to enable/disable the hookYes
hook_typestringMust be set to "sqs"Yes
sqs_queue_urlstringThe AWS SQS queue URLYes
sqs_regionstringThe AWS region where the SQS queue is located (e.g., “us-east-1”)Yes
sqs_auth_typestringAuthentication type: "keys" for access key/secret or "resource" for role-based authYes
sqs_keystringAWS access key ID (required if auth_type is “keys”)Yes if using key auth
sqs_secretstringAWS secret access key (required if auth_type is “keys”)Yes if using key auth
event_typesarrayArray of event types this hook should handleNo. Not provided or empty array means subscribe to all existing and future events.

SQS Permissions

Stream needs the right permissions on your SQS queue to be able to send events to it. If updates are not showing up in your queue add the following permission policy to the queue:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1459523779000",
      "Effect": "Allow",
      "Action": [
        "sqs:GetQueueUrl",
        "sqs:SendMessage",
        "sqs:SendMessageBatch",
        "sqs:GetQueueAttributes"
      ],
      "Resource": ["arn:aws:sqs:region:acc_id:queue_name"]
    }
  ]
}

Here’s an example list of messages read from your SQS queue:

SQS Best practices and Assumptions

  • Set the maximum message size set to 256 KB.

Messages bigger than the maximum message size will be dropped.

  • Set up a dead-letter queue for your main queue.

This queue will hold the messages that couldn’t be processed successfully and is useful for debugging your application.