Before Message Send Webhook

Sometimes you want to have more control over what users are allowed to post and either discard or edit their messages when they do not meet your content guidelines.

This webhook gets called before the message reaches the API and therefore before it is saved to the channel and observable by other users. This allows you to intercept a message and make sure that inappropriate content will never be displayed to other users.

You can use this webhook to enforce any of these rules:

• Scrub PII from messages (ie. social security numbers, credit cards, etc.)

• Restrict contact information sharing (ie. discard phone numbers, emails)

• Validate messages do not include complex words that are best matched using a regular expression (regex)

Your endpoint will receive a POST request with a JSON encoded body containing the message, user, and channel objects:

The request_info object holds information about the client that performed the request. You can use this as an additional signal for what to do with the message. For example, you may block the message from being sent based on IP.

When configuring the SDK, you may also set an additional x-stream-ext header to be sent with each request. The value of this header is passed along as an ext field in the request_info. You can use this to pass along information that may be useful, such as device information. Refer to the SDK-specific docs on how to set this header.

For example, in Javascript, you can set the value like this:

The format of the ext header is up to you and you may leave it blank if you don't need it. The value is passed as-is, so you can use a simple value, comma-separated key-values, or more structured data, such as JSON. Binary data must be encoded as a string, for example using base64 or hex encoding.

If you intend to make any change to the message, you should return a JSON encoded response with the same message structure. Please note that not all message fields can be changed, the full list of fields that can be modified is available in the rewriting messages section.

Your endpoint can decide to reject the message and return a user message. To do that the endpoint must return a regular message with type set to error.  Please note that the HTTP response code should be still 200.

You can also decide to modify the message, in this case, you should return the updated version of the message and it will overwrite the user input.

Or by using MML formatted messages:

Not all message fields can be rewritten by your hook handler, fields such as created_at or updated_at, for instance, are reserved and can only be set by Stream Chat APIs. Any non-custom field that is not listed here will be ignored and not updated on the final message.

1. text

2. i18n

3. show_in_channel

4. silent

5. type

6. attachments

7. any custom field

Your webhook endpoint will be part of the send message transaction, so you should avoid performing any remote calls or potentially slow operations while processing the request. Stream Chat will give your endpoint 1 second of time to reply. If your endpoint is not available (ie. returns a response with status codes 4xx or 5xx) or takes too long, Stream Chat will continue with the execution and save the message as usual.

To make sure that an outage on the hook does not impact your application, Stream will pause your webhook once it is considered unreachable and it will automatically resume once the webhook is found to be healthy again.

An example of how to configure this webhook can be found in this repo.