---
title: "Submit an event asynchronously"
method: POST
path: "/v6/async-events"
tags: ["Events"]
---

# Submit an event asynchronously

`POST /v6/async-events`

Submits a consumer event asynchronously. No per-request rate limit - use for high-volume or bulk integrations. May return 429 only if the downstream ingestion queue is saturated. Only `event_id` is returned; person identification occurs asynchronously after the request returns.

## Request body

- EventDispatcherRequest
  - `data` EventSubmissionData, nullable, required — Open map of fields submitted with an event. May include keys beyond those listed here. `email` is the primary identity key and the only field that enables profile merging. `partner_user_id` is a secondary lookup key and is not guaranteed unique.
    - `email` string, email — Primary identity key. The only data-map field that enables profile merging when submitted.
    - `event_time` string, date-time — ISO 8601 timestamp of when the event occurred. Optional; defaults to the time the request is received. Use for backdated events. On wrapped request bodies this is an alternative to the top-level `event_time` field.
    - `partner_user_id` string — Secondary lookup key for an existing profile. Not guaranteed unique across your program.
    - `person_id` integer — Extole person identifier. Numeric. Submit to target an existing profile instead of resolving by email or partner user id.
  - `event_name` string, required — Name of the event being submitted (for example, `conversion` or `registration`). Required.
  - `event_time` string, required — ISO 8601 timestamp of when the event occurred. Optional; defaults to the time the request is received. Use for backdated events.

## Response `200`

Event accepted and queued for asynchronous processing. Returns the assigned `event_id`. Person identification completes after the response is returned.

- EventDispatcherAsyncResponse
  - `event_id` string, required — Unique identifier for the queued event. Person identification occurs asynchronously after the request returns.

## Other responses

- `400` — Bad request. The named examples below cover this operation's specific validation errors. Other 400 causes include malformed JSON, an invalid `Time-Zone` header, and an empty request body - inspect the response `code` field for the specific error.
- `401` — Unauthorized
- `402` — Payment Required
- `403` — Forbidden
- `415` — Unsupported Media Type
- `429` — Too Many Requests

---

[API](https://skmtc.net/extole/apis/integration-api-server-to-extole.md) · [All operations](https://skmtc.net/extole/apis/integration-api-server-to-extole/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/extole/integration-api-server-to-extole/revisions/c16e62e66755/schema)