---
title: "processErpUpdatesEventsV3"
method: POST
path: "/v3/erp/updates/events"
tags: ["erp"]
---

# processErpUpdatesEventsV3

`POST /v3/erp/updates/events`

Handles updates from ERP systems using integration_id directly.
This is the v3 version that removes the unused event_type field and renames object_type to event_name
to align with the integration UI naming.

## Request body

- ErpUpdatesEventsV3Request
  - `integration_id` string, uuid, required — UUID that identifies the integration configuration to use
  - `correlation_id` string — Optional ID that identifies the specific request for debugging purposes
  - `group_id` string — Controls ordering and parallelism for this request's events. By default, all events for a given `integration_id` are processed **strictly in order, one at a time**. For high-volume integrations this can become a throughput bottleneck. Set `group_id` to opt into **parallel processing**: - Events sharing the same `group_id` are processed in the order received. - Events with different `group_id` values are processed in parallel. Typical usage is to derive `group_id` from a logical partition key in your payload — for example the customer ID, contract ID, or meter ID — so updates to the same business object remain ordered while unrelated objects are processed concurrently. Notes: - Individual events may set their own `group_id`, which overrides this request-level value for that event only. - Up to 20 groups per integration are processed concurrently. Using more distinct values than that yields no additional parallelism. - Omit this field if strict per-integration ordering is required.
  - `events` ErpEventV3[], required — List of ERP events to process
    - union
      - object
        - `event_name` string, required — Event name from integration mapping (e.g., business_partner, contract_account). Required when use_case_slug is not provided.
        - `timestamp` string, date-time, required — Timestamp when the event occurred
        - `format` 'json' | 'xml', required — Format of the payload data
        - `payload` union, required — The object data payload - can be either a serialized string or a direct JSON object
          - string — The serialized object data payload (JSON, XML, etc.) as a string
          - object — Direct JSON object (will be automatically serialized)
        - `use_case_slug` string — Recommended. Use case slug for routing this event to the correct use case configuration. If provided, takes precedence over event_name for use case lookup. Preferred over event_name-based routing as slugs are portable across environments.
        - `deduplication_id` string — Optional unique identifier for idempotency - prevents duplicate processing of the same event within 24 hours in context of the same integration. Must contain only alphanumeric characters, hyphens, and underscores.
        - `group_id` string — Optional per-event ordering group. Overrides the request-level `group_id` for THIS event; when absent, the event inherits the request-level `group_id` (or the default strict per-integration ordering). Use it when a single batch carries events for unrelated business objects that may be processed in parallel. See the request-level `group_id` for semantics.
      - object
        - `event_name` string — Event name from integration mapping (e.g., business_partner, contract_account). Required when use_case_slug is not provided.
        - `timestamp` string, date-time, required — Timestamp when the event occurred
        - `format` 'json' | 'xml', required — Format of the payload data
        - `payload` union, required — The object data payload - can be either a serialized string or a direct JSON object
          - string — The serialized object data payload (JSON, XML, etc.) as a string
          - object — Direct JSON object (will be automatically serialized)
        - `use_case_slug` string, required — Recommended. Use case slug for routing this event to the correct use case configuration. If provided, takes precedence over event_name for use case lookup. Preferred over event_name-based routing as slugs are portable across environments.
        - `deduplication_id` string — Optional unique identifier for idempotency - prevents duplicate processing of the same event within 24 hours in context of the same integration. Must contain only alphanumeric characters, hyphens, and underscores.
        - `group_id` string — Optional per-event ordering group. Overrides the request-level `group_id` for THIS event; when absent, the event inherits the request-level `group_id` (or the default strict per-integration ordering). Use it when a single batch carries events for unrelated business objects that may be processed in parallel. See the request-level `group_id` for semantics.

## Response `200`

Some events failed to process

- object
  - `results` object[]
    - `event_id` string, required — ID of the processed event
    - `status` 'success' | 'error' | 'skipped' | 'ignored', required — Processing status for the event (skipped indicates duplicate deduplication_id, ignored indicates unconfigured event)
    - `message` string

## Other responses

- `400` — Bad request
- `401` — Unauthorized request
- `404` — Resource not found
- `500` — Internal Server Error

---

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