Calendar integrations look simple until you ship them. Then the cracks show up immediately: Google and Outlook disagree on how to interpret recurrence rules, Apple refuses to send RSVP emails, ICS behaves differently depending on the client, and every vendor expects a slightly different flavour of timestamps, timezone notation and participant data. The longer the system runs, the more patches you end up writing to keep events in sync.

Synara exists because those problems aren’t edge cases — they’re the baseline.

This walkthrough shows the shortest path to building a working integration using Synara. Not the marketing version — the real version. The part developers care about: how to create an event, how Synara handles the chaos behind the scenes, and what your system receives back.

1. Start by creating a project in the Developer Console

Everything in Synara is scoped to a project. When you create one, you’re not just naming a sandbox — you’re setting up the container that will hold all your events, their logs, their webhooks, and their associated configuration.

It’s the place where you’ll see a single timeline for everything Synara does on your behalf: the JSCalendar you send in, the ACE Synara converts it into, the ICS fallback it generates, and the events flowing out as webhooks.

In other words: this console is how you see the system you're building.

2. Get your API key

You only need one. And unlike most calendar-related APIs, you don’t have to juggle three providers with three different authentication models. Synara, by design, is the single “front door” — the layer between you and the vendors.

This key is what your application uses to send JSCalendar, update events, and verify webhooks. There’s no OAuth dance unless your users choose to sync their calendars later.

3. Create your first event by sending JSCalendar to Synara

Most systems that accept event data expect partial structures, implicit fields or vendor-specific formatting. Synara doesn’t. It expects JSCalendar — a modern, structured spec designed for events, with predictable semantics.

You define the event in JSCalendar exactly as your application understands it: summary, start, end, timezone, participants, recurrence rules, and metadata. That’s your source of truth.

When Synara receives it, something important happens:

• Synara does not store JSCalendar directly.
• Instead, it converts it into ACE — its internal event representation.

This is the backbone of Synara. ACE is what allows Synara to work consistently even when clients behave inconsistently. You never send ACE, but you always receive it.

And alongside ACE, Synara generates the ICS fallback — because the world still needs it, even if we all wish it didn’t.

The moment the event is created, Synara sends invitations and prepares itself to track the event over time.

4. Watch what comes back: ACE-normalised webhooks

This is the part where you normally end up writing defensive code in every calendar integration.

• Google might send updates, or it might not.
• Outlook might notify you of a change, or quietly mutate the event.
• Apple might accept an invite without telling you.
• ICS might encode the RSVP in a way that only some clients interpret correctly.
• Timezones might roundtrip incorrectly and shift the event.

You can’t build reliable behaviour on that.

Synara shields you from it. Every webhook you receive arrives in ACE, not raw ICS and not a vendor-specific payload. It’s already been normalised so your system doesn’t need branching logic for each provider.

Whether the attendee accepted from Gmail, or Outlook desktop, or Apple Calendar, or via the Synara email UI — the webhook is consistent.

This is the core promise: your integration logic doesn’t grow over time. The complexity stays inside Synara.

5. Update the event by sending JSCalendar again

Most calendar systems treat updates as deltas or patches. Synara doesn’t. You simply send an updated JSCalendar object, and Synara reconciles it.

You’re not manually editing timestamps, rewriting recurrence rules to satisfy Outlook, or stripping fields that Apple will reject. You keep one JSCalendar representation in your application, and Synara handles the transformations.

It then:

• updates the ACE model
• regenerates the ICS fallback
• notifies attendees
• propagates changes to connected calendars
• emits fresh ACE webhooks

The behaviour is predictable because the format is predictable.

6. Use the Developer Console to inspect the entire lifecycle

This is to stop the classic debugging hell of:

• “Did Outlook change the event?”
• “Why did Google add a second VEVENT block?”
• “Why is the timezone suddenly floating?”
• “Where did the RSVP come from?”

In the console, you can inspect:

• the JSCalendar you sent
• the ACE Synara created
• the ICS fallback
• the attendee timeline
• the exact webhook payloads
• retries, failures, pending deliveries
• past versions of the event

This visibility is what most calendar platforms never give you.

You see the system you’re building, rather than guessing at it.

Why this approach survives real-world use

If you’ve ever built even a small scheduling tool, you already know the failure modes:

• ICS is parsed differently by every client
• Outlook invalidates recurrence rules silently
• Apple reads some properties and ignores others
• RSVP flows are inconsistent across clients
• Timezones mutate when clients import events
• Vendor APIs behave unpredictably over time

Traditional integrations degrade because the integration becomes a patchwork of exceptions. The longer it runs, the worse it gets.

Synara avoids that entirely by splitting responsibilities cleanly:

• You maintain one JSCalendar representation.
• Synara maintains one internal ACE representation.
• ICS is produced as a compatibility layer, not a primary format.
• Webhooks arrive in ACE, not vendor-specific formats.
• Debugging is centralised, not scattered across provider dashboards.

The result is an integration that doesn’t grow accidental complexity.

This is what calendar infrastructure should have looked like from the start.