Customer.io Pipelines API

*You **only** need to use this method to support a few select destinations like Mixpanel.* The `alias` method reconciles identifiers in systems that don't automatically handle identity changes—like when a person graduates from an anonymous user to an identified user. For example, a person typically has an `anonymousId` until you identify them by `userId`. Most destinations will automatically associate data from the anonymous ID with the new user ID when you send an `identify` call. But a select few destinations, like [Mixpanel](/integrations/data-out/connections/mixpanel/), won't! The `alias` call tells Mixpanel to represent the `anonymousId` with the new `userId`. If you need to use the `alias` call, you'll want to send it before you identify someone with a `userId`. If you use our web or server-side libraries, and you've already identified someone, we assume that this is the `userId` that you want to keep. Otherwise, you need to pass both the `previousId` and the `userId`. **When you use our libraries, you'll typically only provide the `previousId` and `userId`. The libraries fill in the rest of the payload automatically.**

The batch method helps you send an array of `identify`, `group`, `track`, `page` and/or `screen` requests in a single call, so you don't have to send multiple requests. Our server-side sources use this method automatically to increase performance. Requests are limited to 500KB total per request and 32KB per call in the request. In a batch request, the `context` and `integrations` objects apply to _all calls in the request_. You can't set different context or integrations values for different calls in the same request.

Group calls add people to a group. Groups could be a companies, accounts, online classes, and so on. How groups are represented in your destination depends on the destination. Some destinations have concepts of "groups"; Customer.io's destination calls groups "objects." **When you use our libraries, you'll typically only provide an ID for the user, the `groupId`, and `traits`. The libraries fill in the rest of the payload automatically.**

Identifies a person and assigns `traits` to them. In most cases, you'll identify people with a `userId` or an `anonymousId`. But when you use Customer.io as a destination, you can pass an empty `userId` or `anonymousId`, and identify people by their `email` trait. **When you use our libraries, you'll typically only provide an ID and `traits`. The libraries fill in the rest of the payload automatically.**

Sends a page view event. If you use our JavaScript source, it automatically records `page` events whenever it loads (every page). If you use a single-page app, you'll need to call the `page` method people change routes. The request consists of the page `name` and additional properties about the page. If you use our JavaScript library, the page name and URL are automatically gathered and passed as event properties. **When you use our libraries, you'll typically only provide a user ID/anonymous ID and the `name` of the page. The libraries fill in the rest of the payload automatically.**

Sends a screen view event for mobile devices. Screen events help you understand the screens that people use in your app. You should send a screen call whenever a user requests a page of your app.

Send an event associated with a person. The `track` call is how you record the things that people do on your website or in your app. While this endpoint takes any `event` name you want to send, Customer.io also supports "semantic events." These are specific `event` names (like `User Deleted` or `Device Created or Updated`) that perform special operations in Customer.io like deleting people, adding mobile devices to profiles, and so on. See the [Customer.io Semantic Events documentation](/integrations/api/cdp/customerio/) for complete schemas and examples. **When you use our libraries, you'll typically only provide an `event`, an ID for the person, and `properties`. The libraries fill in the rest of the payload automatically.**