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

# Syncing changes

> Keep a CRM or a sheet up to date with what TIKT finds and what changes, without reading everything again.

There are two ways to follow what happens in your workspace. Most integrations use the first; the second is the safety net.

| | How | When to use it |
| - | - | - |
| **Webhooks** | TIKT calls your address within minutes of each event. | You have a tool that can receive requests: n8n, Make, Zapier, Clay, your own server. See [Webhooks](/webhooks). |
| **The event log** | You call `GET /v1/events` from time to time and get what happened since your last call. | Your tool can only make requests on a schedule, or you want to catch up after downtime. |

Both carry **the same events, in the same envelope**: the same `id`, `type`, `created_at` and `data`. A sync can mix them — receive webhooks, and read the log after an outage to fill the gap.

## Read the event log

The first time, start from a date:

```bash theme={null}
curl "https://api.trytikt.com/v1/events?since=2026-10-01T00:00:00Z&type=lead.created,lead.engaged_again" \
  -H "Authorization: Bearer $TIKT_API_KEY"
```

Events come **oldest first**, up to 100 per page (`limit`), with the [usual pagination](/api/pagination). Keep the `id` of the **last event you handled**: next time, ask for what comes after it.

```bash theme={null}
curl "https://api.trytikt.com/v1/events?after=<id of the last event you handled>" \
  -H "Authorization: Bearer $TIKT_API_KEY"
```

| Parameter | |
| - | - |
| `after` | The `id` of the last event you handled: only the events written after it. An `id` TIKT doesn't know (another workspace's, or older than 180 days) is refused with `400`. |
| `since` | A date (ISO 8601): the events written from then on. Not together with `after` or `cursor`. |
| `type` | One or more event types, separated by commas. All of them by default — the list is in [Events](/webhooks/events). |

What the log guarantees:

* **In the order TIKT wrote them**, and **never one skipped**: an event appears only once everything written before it is complete. The price is a delay of a few seconds at most.
* **180 days** of history. `lead.matched` (a [workflow](/webhooks/workflows) match) is in the log; test events are not.
* `data` is the object **as it is now**, like a resend: a lead read today has today's score.

## Follow new engagements

To know who engaged with which post — every reaction and comment of your leads — read the engagement feed, oldest first, from a date:

```bash theme={null}
curl "https://api.trytikt.com/v1/signals?captured_after=2026-10-20T00:00:00Z" \
  -H "Authorization: Bearer $TIKT_API_KEY"
```

Each item is `{ "lead_id", "signal" }`: the lead, and the engagement with its post and tracked profile. Filter with `kol_id`, `post_id`, or `kind` (`reaction`, `comment`, `reply`). Only engagements of your **leads** are there, never those of people who aren't.

## Example: keep a CRM up to date

A scenario that runs every 15 minutes:

1. Read the bookmark you saved last time — the `id` of the last event handled.
2. `GET /v1/events?after=<bookmark>&type=lead.created,lead.status_changed,list.lead_added`, page after page until `has_more` is `false`.
3. For each event, in order:
   * `lead.created` → create the contact from `data.lead.person` and `data.lead.company`;
   * `lead.status_changed` → when the lead was discarded, mark the contact;
   * `list.lead_added` → tag the contact with the list's name.
4. Save the `id` of the last event as the new bookmark — only after the CRM has accepted the changes, so a failed run starts again from the same place.

Then answer TIKT from the CRM: when a contact is marked as contacted, file the lead in a list with `POST /v1/lists/{id}/leads` — see **Respond to TIKT** in the [n8n](/guides/n8n#respond-to-tikt), [Make](/guides/make#respond-to-tikt), [Zapier](/guides/zapier#respond-to-tikt) and [Clay](/guides/clay#respond-to-tikt) guides.


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