Tidy up commit

Author: franrob-projects

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

@@ -98,10 +98,10 @@ To ensure that publishes are [idempotent](/docs/pub-sub/advanced#idempotency), a
 
 ## Publishing from Zapier <a id="zapier"/>
 
-Zapier can publish messages to Ably channels when other apps trigger events. This works well for connecting spreadsheets, forms, emails, and other services to your realtime channels.
+Zapier can publish messages to Ably channels when other apps trigger events. This connects spreadsheets, forms, emails, and other services to realtime channels.
 
-In Zapier, create a new Zap and choose your trigger (like a new spreadsheet row). Then add Ably as an action - you'll find "Publish Message" and "Publish Push Notification" options. You'll need to provide your API key from the Ably dashboard.
+In Zapier, create a new Zap and choose a trigger (like a new spreadsheet row). Add Ably as an action with "Publish Message" and "Publish Push Notification" options. Provide the API key from the Ably dashboard.
 
-Set up your message with the channel name and content. For push notifications, you can also add a title and body for the notification itself.
+Set up the message with the channel name and content. For push notifications, add a title and body for the notification itself.
 
-Use Zapier's test button to check it works, then watch for messages in the Ably Dev Console.
+Use Zapier's test button to verify functionality, then watch for messages in the Ably Dev Console.

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

@@ -50,21 +50,21 @@ Whilst pub-sub channels broadcast messages to all subscribers, queues distribute
 
 ## Debugging integrations <a id="debugging"/>
 
-If messages aren't reaching your endpoint, try these steps:
+If messages are not reaching the endpoint, follow these steps:
 
-First, check your integration setup in the Ably dashboard. Make sure the URL is correct and your channel filter matches the channels you're testing.
+1. Check the integration setup in the Ably dashboard. Verify the URL is correct and the channel filter matches the channels being tested.
 
-Use the Test rule button to verify Ably can reach your endpoint. This tests the connection directly.
+2. Use the Test rule button to verify Ably can reach the endpoint. This tests the connection directly.
 
-If that works, publish a test message through the Dev Console to the channel your integration monitors. Check the Dev Console logs to see if the message was delivered. Errors can take up to 15 seconds to appear due to retry attempts.
+3. If the connection test succeeds, publish a test message through the Dev Console to the channel the integration monitors. Check the Dev Console logs to see if the message was delivered. Errors can take up to 15 seconds to appear due to retry attempts.
 
-Common issues include regex patterns that don't match your channels, authentication problems, and endpoints that don't respond quickly enough.
+Common issues include regex patterns that do not match channels, authentication problems, and endpoints that do not respond quickly enough.
 
 ### Integration failure logs
 
-When integrations fail (your endpoint returns an error), Ably logs the details to the `[meta]log` metachannel. These logs include the failure reason (like "POST returned HTTP status 500"), along with the rule ID, message ID, and channel name.
+When integrations fail (endpoint returns an error), Ably logs the details to the `[meta]log` metachannel. These logs include the failure reason (such as "POST returned HTTP status 500"), along with the rule ID, message ID, and channel name.
 
-You can see these failures live in the Dev Console, or use the history API to check past failures. You can also attach to the `[meta]log` channel with rewind to see the last 100 messages.
+View these failures live in the Dev Console, or use the history API to check past failures. Attach to the `[meta]log` channel with rewind to see the last 100 messages.
 
 ## Skip integrations <a id="skip"/>
 

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

@@ -80,15 +80,15 @@ A [Dead Letter Queue](#deadletter) is automatically created. It stores messages
 
 ### Modifying queues <a id="modify"/>
 
-Queues can't be changed after creation - they're immutable. If you need different settings, you'll need to create a new queue and migrate.
+Queues cannot be modified after creation - they are immutable. Different settings require creating a new queue and migrating.
 
-This includes limits like TTL and max length. Even if you upgrade your Ably account, existing queues keep the limits they were created with. You'll need to replace them to get the higher limits from your new plan.
+This includes limits like TTL and max length. Even after 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.
 
-Here's how to switch to a new queue:
+Steps to switch to a new queue:
 
-1. Create a new queue with your desired settings
-2. Update your consumers to subscribe to both the old and new queues
-3. Change your queue rules to route messages to the new queue
+1. Create a new queue with the desired 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
 
@@ -502,33 +502,33 @@ Ably names the Dead Letter Queue using the reserved format `APPID:deadletter`, w
 
 ## Troubleshooting queue connections <a id="troubleshooting"/>
 
-Can't connect to your queue? Here's what usually goes wrong.
+Common queue connection issues:
 
-Use port 5671, not the standard AMQP port 5672. We only support TLS connections.
+**Port Configuration**: Use port 5671, not the standard AMQP port 5672. Only TLS connections are supported.
 
-Your API key needs queue subscribe permissions. Check this in your dashboard under App Keys if you're getting auth errors.
+**API Key Permissions**: The API key needs queue subscribe permissions. Check this in the dashboard under App Keys for authentication errors.
 
-We use AMQP 0.9.1. Older clients might not support this version.
+**AMQP Version**: AMQP 0.9.1 is required. Older clients might not support this version.
 
-Don't declare queues or bind exchanges. Ably queues already exist - just connect to the queue name directly.
+**Queue Declaration**: Do not declare queues or bind exchanges. Ably queues already exist - connect to the queue name directly.
 
-Getting authentication errors? Your username is everything before the colon in your API key, password is everything after.
+**Authentication Format**: The username is everything before the colon in the API key, password is everything after.
 
-Some clients struggle with our "shared" vhost. Make sure that's what you're using.
+**Virtual Host**: Use the "shared" vhost. Some clients may have difficulty with this configuration.
 
-Connection timing out? Try increasing your client timeout settings.
+**Connection Timeout**: Increase client timeout settings if connections are timing out.
 
-No messages showing up? Check your queue rules and channel filters are set correctly.
+**Message Delivery**: Verify queue rules and channel filters are configured correctly if no messages appear.
 
 ## Production considerations <a id="production"/>
 
-Ably Queues work well for testing and lower-volume applications, but have some limitations for production use at scale.
+Ably Queues work well for testing and lower-volume applications, but have limitations for production use at scale.
 
-The multi-tenanted queue service has periodic maintenance windows that can cause brief downtime. This is different from Ably's core platform which has stronger uptime guarantees.
+The multi-tenanted queue service has periodic maintenance windows that can cause brief downtime. This differs from Ably's core platform which has stronger uptime guarantees.
 
-If you're building a production system that needs high throughput or can't handle maintenance downtime, consider using [streaming integrations](/docs/platform/integrations/streaming) instead. These let you pipe data into dedicated queue services like SQS, RabbitMQ, or Kinesis that you control.
+For production systems requiring high throughput or that cannot handle maintenance downtime, consider using [streaming integrations](/docs/platform/integrations/streaming) instead. These allow data to be piped into dedicated queue services like SQS, RabbitMQ, or Kinesis under direct control.
 
-For enterprise customers with high-volume needs, we offer dedicated queue clusters that scale to millions of messages per second.
+For enterprise customers with high-volume needs, dedicated queue clusters are available that scale to millions of messages per second.
 
 ## Queue scalability <a id="scalability"/>
 

src/pages/docs/platform/integrations/streaming/datadog.mdx

@@ -30,17 +30,14 @@ The following steps setup the Datadog integration:
 
 ## Troubleshooting integration states <a id="troubleshooting"/>
 
-Having trouble connecting? Here's what usually goes wrong.
+Common connection issues:
 
-Stuck on "Connecting"? Your connection probably got interrupted. Contact support if it won't budge.
+* Stuck on "Connecting": Connection was interrupted. Contact support if the status does not change.
+* Getting "Connection failed": Contact support for assistance.
+* "API key with this name already exists": The key already exists in Datadog. Delete the existing key first.
+* "Forbidden" or permission errors: Datadog Admin permissions are required to set up this integration.
 
-Getting "Connection failed"? Same deal - reach out to support.
-
-"API key with this name already exists"? You've already got that key in Datadog. Delete the old one first.
-
-"Forbidden" or permission errors? You need Datadog Admin permissions to set this up.
-
-Once it's working, hit "See Dashboard" in Ably to jump over to Datadog. Your data shows up every minute.
+After successful setup, select "See Dashboard" in Ably to navigate to Datadog. Data appears every minute.
 
 ## Remove access <a id="remove"/>
 

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

@@ -103,13 +103,13 @@ The back off for consecutively failing requests will increase until it reaches 6
 
 ## Message ordering <a id="ordering"/>
 
-Webhooks don't always preserve message order the same way Ably channels do. It depends on how you've set up your webhook.
+Webhooks do not always preserve message order the same way Ably channels do. This depends on the webhook configuration.
 
-With batched webhooks, messages stay in order as long as they're from the same publisher on the same channel. If a batch fails and gets retried, newer messages get included but they'll still be in the right order. Messages from different regions might arrive in separate batches, but that's fine since ordering is per-publisher anyway.
+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 can't guarantee order. Each message fires off its own HTTP request, and there's no telling which one arrives first. If your server supports HTTP/2 though, you get ordering back because requests get pipelined down one connection.
+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.
 
-One gotcha: if you're publishing via REST (not realtime), you lose ordering guarantees even with batching on. That's because REST uses a connection pool where requests can finish out of order.
+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

@@ -110,13 +110,13 @@ Then ensure the checkbox for the policy is selected.
 
 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).
 
-This means your Lambda function might occasionally run multiple times for the same Ably event. Design your functions to handle this - either make them idempotent or check for duplicate processing.
+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.
+Configure retry behavior in the 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.
 
 ## Example Lambda function <a id="example"/>
 
-Here's a Lambda function that processes events from Ably and publishes a message back. You'll need to bundle this with the Ably client library when you upload it.
+The following Lambda function processes events from Ably and publishes a message back. Bundle this with the Ably client library when uploading.
 
 <Code>
 ```javascript
@@ -149,6 +149,6 @@ exports.handler = (event, context, callback) => {
 ```
 </Code>
 
-A few things to watch out for: use `Ably.Rest` instead of `Ably.Realtime` since you don't want to open websockets just for publishing. Make sure you publish to a different channel than the one triggering this Lambda, or you'll get stuck in a loop. And always call the callback inside the publish callback - otherwise your function might finish before the publish request goes out.
+Important considerations: Use `Ably.Rest` instead of `Ably.Realtime` to avoid opening websockets for publishing. Publish to a different channel than the one triggering this Lambda to prevent loops. Always call the callback inside the publish callback to prevent the function from finishing before the publish request completes.
 
-There's a complete working example at [github.com/ably/example-lambda-function](https://github.com/ably/example-lambda-function) that you can download and deploy.
+A complete working example is available at [github.com/ably/example-lambda-function](https://github.com/ably/example-lambda-function) for download and deployment.

src/pages/docs/platform/pricing/limits.mdx

@@ -107,9 +107,9 @@ Integration limits relate to the rate and concurrency of [webhooks](/docs/platfo
 
 ### Why integration rate limits exist
 
-Rate limits prevent issues when there's a mismatch between your channel message rate and your endpoint's processing capacity. Without limits, messages could queue up invisibly, creating backlogs you can't monitor or manage.
+Rate limits prevent issues when there is a mismatch between channel message rate and endpoint processing capacity. Without limits, messages could queue up invisibly, creating backlogs that cannot be monitored or managed.
 
-For high-volume scenarios, use an intermediary queue like [AWS Kinesis](/docs/platform/integrations/streaming/kinesis) instead of direct webhook delivery. This provides better visibility into message backlogs and allows you to batch process messages or discard stale ones.
+For high-volume scenarios, use an intermediary queue like [AWS Kinesis](/docs/platform/integrations/streaming/kinesis) instead of direct webhook delivery. This provides better visibility into message backlogs and allows batch processing of messages or discarding of stale ones.
 
 | Integration limit | Free | Standard | Pro | Enterprise |
 | ----------------- | ---- | -------- | --- | ---------- |