The /i/v0/e and /batch endpoints are the main way to send events to PostHog. Beyond user behavior, they are also used to identify users, update person or group properties, migrate from other platforms, and more. Our SDKs handle the different event types for you, but with the API, you need to send the right type of event (listed below) to trigger the functionality you want.
Both are POST-only public endpoints that use your project token and do not return any sensitive data from your PostHog instance.
Note: Make sure to send API requests to the correct domain. These are https://us.i.posthog.com for US Cloud, https://eu.i.posthog.com for EU Cloud, and your self-hosted domain for self-hosted instances. Confirm yours by checking your URL from your PostHog instance.
Here are examples of the types of events you can send:
Single event
Every event request must contain an api_key, distinct_id, and event field with the name. Both the properties and timestamp fields are optional.
> **Note:** If the provided `distinct_id` has ever been used with an identified event, the event will still be treated as identified.
</MultiLanguage>
## Batch events
You can capture multiple events in one request with the `/batch` API route. There is no limit on the number of events you can send in a batch, but the entire request body must be less than 20MB by default.
This example shows how the required `distinct_id` value can also be passed in `properties`.
The historical_migration field is optional. For realtime events, it can be left out or set to false.
Historical migrations
When running migrations, the historical_migration field must be set to true. This ensures that events are processed in order without triggering our spike detection systems.
Captures event with a group. In this case, company is a group type. You can set it to the value you want such as organization, project, or channel. Read more in our group analytics docs.
Note: This event will not create a new group if a new key being used. To create a group, see the group identify event.
Updates person properties. Read more in our identify docs.
Note: The $identify event works differently from the identify() method in the JavaScript SDK. This event updates the person properties, while the JavaScript identify() method connects an anonymous user and a distinct ID.
Note: For a server-side integration with Web Analytics, check out our Server SDKs and Sessions guide to make sure you're capturing every event and session property required for our product to work.
Although there is a lot of functionality you miss out on if you only use the API, you can capture survey related events. These include survey sent, survey shown, and survey dismissed, each of which requires $survey_id as a property. Read our docs on implementing custom surveys for more information.