Changes to Calendar Webhook Data: What You Need to Know
In this article, we'll cover:
- What we're changing and why
- What to check before the update
- Changes in Calendar webhook data
- A before-and-after example
- What stays the same
- What's next for the Calendar API
What's changing and why
We're bringing Calendar webhook data into line with Flowlu's open API format. This will help us keep the data format consistent and make future integrations easier to build and maintain.
All Calendar webhooks will switch to the new format on October 19, 2026. The old format will no longer be available.
What to check before the update
If your integrations handle Calendar event creation, updates, or deletion, check the following:
- Data types: Make sure your handlers support numbers and
nullvalues instead of strings. - Field names: Update references to renamed or removed fields.
- Missing fields: Check that your code doesn't assume every field is present.
- Dates: If time zones matter, use the new
*_f_atomfields.
You won't be able to test the new format with live webhook data before the release. Use the examples below to prepare, then check the first webhook deliveries once the update goes live.
Changes in Calendar webhook data
1. Data types
Previously, all values were sent as strings:
"id": "965848", "status": "1"
After the update, numbers will remain numbers, and empty values can be sent as null:
"id": 965849, "status": 1, "deleted_at": null
Review any strict comparisons or string conversions in your code.
2. Included fields
Previously, webhook data contained all entity fields, including empty ones such as deadline, priority, cost, and time_estimate.
After the update, only fields with values and key event attributes will be included.
Check whether a field exists before using it.
3. Renamed and removed fields
| Previous field | New field |
created |
created_date |
created_by |
owner_id |
changed |
updated_date |
changed_by |
updated_by |
crm_company_id |
crm_account_id |
status_changed_date |
status_updated_date |
status_changed_by |
status_updated_by |
The author_id and crm_contact_id fields will no longer be sent.
If you previously used author_id, switch to owner_id, which identifies the event organizer.
4. Dates in ISO 8601 format
Each date field will have an additional field with the _f_atom suffix, containing the portal's time zone offset.
For example:
"plan_start_date_f_atom": "2026-10-15T11:08:00+05:00"
We recommend using these fields when working with dates and time zones.
Example: creating a Calendar event
Before:
{
"current": {
"id": "965849",
"name": "Meeting with a client",
"status": "1",
"all_day": "1",
"responsible_id": "2002",
"created": "2026-10-08 11:09:04",
"deadline": "",
"priority": "2",
"time_estimate": ""
}
}
After:
{
"current": {
"id": 965849,
"name": "Meeting with a client",
"status": 1,
"all_day": 1,
"responsible_id": 2002,
"created_date": "2026-10-08 11:09:04",
"created_date_f_atom": "2026-10-08T11:09:04+05:00",
"plan_start_date_f_atom": "2026-10-15T11:08:00+05:00"
}
}
The examples show the current block. The meta structure remains unchanged.
What stays the same
- The webhook delivery mechanism and
metastructure (module,model,action). - Original date fields without the
_f_atomsuffix. They retain theYYYY-MM-DD HH:MM:SSformat in the portal's time zone. - The
previousblock for event updates, although its data will follow the new formatting rules.
What's next
With this update, we're preparing Calendar for its open API.
The upcoming API will support listing, retrieving, creating, updating, and deleting events, along with separate operations for recurring events. It will also include filters by calendar and date, with documentation for each method.
We'll share more details when the Calendar API is ready.
In the meantime, if you have any questions about the update or need help preparing your integrations, feel free to reach out to us at [email protected].
