Remove integrations section of FAQs

src/pages/docs/platform/integrations/queues.mdx

@@ -78,6 +78,22 @@ The following steps explain how to provision an Ably Queue:
 A [Dead Letter Queue](#deadletter) is automatically created. It stores messages that fail to be processed, or expire.
 </Aside>
 
+### Modifying queues <a id="modify"/>
+
+Queues cannot be modified after creation because they are immutable. Different settings require creating a new queue and migrating.
+
+This includes limits like TTL and max length. Even after [upgrading](/docs/account/billing-and-payments#upgrading) an Ably account, existing queues retain the limits they were created with. Replacement is required to get the higher limits from a new plan.
+
+Steps to switch to a new queue:
+
+1. Create a new queue with the required settings.
+2. Update consumers to subscribe to both the old and new queues.
+3. Change queue rules to route messages to the new queue.
+4. Wait for the old queue to drain completely.
+5. Delete the old queue once empty.
+
+This process ensures no message loss during the transition.
+
 ### Configure a Queue rule <a id="config"/>
 
 After you provision a Queue, create one or more Queue rules to republish messages, presence events, or channel events from channels into that queue.

src/pages/docs/platform/integrations/webhooks/index.mdx

@@ -92,7 +92,15 @@ The backoff delay follows the formula: `delay = delay * sqrt(2)` where the initi
 
 The back off for consecutively failing requests will increase until it reaches 60s. All subsequent retries for failed requests will then be made at 60s intervals until a request is successful. The queue of events is retain for 5 minutes. If an event cannot be delivered within that time then events are discarded to prevent the queue from growing indefinitely.
 
-### Batched event payloads <a id="batched-events"/>
+## Message ordering <a id="ordering"/>
+
+Webhooks do not always preserve message order the same way Ably channels do. This depends on the webhook configuration.
+
+Batched webhooks preserve message order when messages are from the same publisher on the same channel. If a batch fails and gets retried, newer messages are included while maintaining correct order. Messages from different regions might arrive in separate batches, maintaining per-publisher ordering.
+
+Single request webhooks cannot guarantee order. Each message triggers its own HTTP request, and arrival order is not predictable. HTTP/2 server support can restore ordering through request pipelining over a single connection.
+
+Publishing via REST (not realtime) removes ordering guarantees even with batching enabled, as REST uses a connection pool where requests can complete out of order.
 
 Given the various potential combinations of enveloped, batched, and message sources, it's helpful to understand what to expect in different scenarios.
 

src/pages/docs/platform/integrations/webhooks/lambda.mdx

@@ -57,7 +57,6 @@ The following steps show you how to create a policy for an AWS Lambda.
 
 <Code>
 ```json
-{
 {
   "Version": "2012-10-17",
   "Statement": [
@@ -105,3 +104,11 @@ Then ensure the checkbox for the policy is selected.
 8. You don't need to add tags so click **Next: Review**.
 9. Enter a suitable name for your role.
 10. Click **Create Role**.
+
+## Lambda retry behavior <a id="retry"/>
+
+Ably invokes Lambda functions asynchronously using the `event` invocation type. When a function returns an error, AWS Lambda automatically retries the execution up to two more times with delays between attempts (1 minute, then 2 minutes).
+
+Lambda functions might run multiple times for the same Ably event. Design functions to handle this by making them idempotent or checking for duplicate processing.
+
+You can configure retry behavior in your AWS Lambda console under the function's asynchronous invocation settings. See the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) for details on adjusting retry settings.