> ## Documentation Index
> Fetch the complete documentation index at: https://developers.bottari.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Batching

> How changes merge into one event, and when each event is sent.

Property and content events aren't sent immediately. Changes of the same kind to the same target are collected for 60 seconds and sent as one event.

## 60-second batching

An event goes out 60 seconds after the first change. Later changes don't extend the 60 seconds. `timestamp` is the time of the first change.

| Situation | Result |
| - | - |
| Three properties of a row changed over 33 seconds | One `page.properties_updated` about 60 seconds after the first change, with three entries in `updated_properties` |
| A row's property and content changed together | Two events, because the kinds differ |
| A document's content edited several times | One `page.content_updated`, with block IDs merged |
| Several people made the changes | Each appears once in `authors`, in writing order |
| A property renamed, an option changed, and a property added | One `data_source.schema_updated` |

## Events sent right away

These events aren't collected. A check that runs every 2 seconds sends them.

* `page.locked`, `page.unlocked`
* `data_source.content_updated`
* `comment.created`, `comment.updated`, `comment.deleted`

## Merged or skipped events

### Edits right after creation

Properties changed within 60 seconds of creation are absorbed into `page.created`. No `page.properties_updated` is sent, and only `authors` merges.

| Subscription | What it receives |
| - | - |
| Selected `page.created` | One `page.created` |
| Didn't select `page.created`, selected `page.properties_updated` | Edits after creation arrive as `page.properties_updated` |

Values set during creation never arrive as `page.properties_updated`, for either subscription. Content changes aren't absorbed and arrive as `page.content_updated`.

### Reverted values

| Change | Result |
| - | - |
| A property value changed and restored within 60 seconds | Sent with `updated_properties: []` |
| The same value written again | Not sent |
| A schema change reverted within 60 seconds, such as creating and deleting a property | Not sent |
| A block edited and restored | The block appears in `updated_blocks` |

### Delete and restore

| Change | Result |
| - | - |
| Deleted and restored within 60 seconds | Neither `page.deleted` nor `page.undeleted` is sent. The same goes for databases. |
| Deleted and restored after more than 60 seconds | `page.deleted`, then `page.undeleted`. Reading back returns `in_trash: false`. |
| Edited and deleted within 60 seconds | The row's other events go out right away. `page.deleted` waits for its own 60 seconds. |

### Rows with subpages

Trashing, restoring, and moving send one event for the topmost target only. Deleting a row that has subpages sends just that row's `page.deleted`. Deleting a subpage first and then the row sends both.

### Changes before a subscription is on

Changes made before verification or before resuming aren't sent. Later changes are sent, even if they fall inside a 60-second period that started earlier.

## Arrival order

Each subscription sends up to 5 events at the same time, so arrival order can differ from change order. When many changes happen at once, events wait and go out in turn.

Don't rely on an event for state. Call the API with the IDs you received to read the current value.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.