Sign in
erp

processErpUpdatesEventsV3

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.

post/v3/erp/updates/events

Request body

integration_idstring uuid required

UUID that identifies the integration configuration to use

correlation_idstring

Optional ID that identifies the specific request for debugging purposes

group_idstring

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.

Example request

{
  "group_id": "customer-42",
  "events": [
    {
      "event_name": "business_partner",
      "timestamp": "2025-05-01T08:30:00Z",
      "format": "json",
      "use_case_slug": "business_partner",
      "deduplication_id": "evt-2025-05-01-12345-bp",
      "group_id": "customer-42",
      "correlation_id": "customer-42-sync-2026-08-26"
    }
  ]
}

Response

Some events failed to process

Changes

Changed in 2 of the 8 revisions of this API.2