v4

latestOpenAPI 3.0.32026-08-0161180264.4 KB

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"
    }
  ]
}

Response

Some events failed to process