This endpoint is used to amend a single usage event with a given event_id
. event_id
refers to the
idempotency_key
passed in during ingestion. The event will maintain its existing event_id
after the amendment.
This endpoint will mark the existing event as ignored, and Orb will only use the new event passed in the body of
this request as the source of truth for that event_id
. Note that a single event can be amended any number of
times, so the same event can be overwritten in subsequent calls to this endpoint. Only a single event with a given
event_id
will be considered the source of truth at any given time.
This is a powerful and audit-safe mechanism to retroactively update a single event in cases where you need to:
This amendment API is always audit-safe. The process will still retain the original event, though it will be ignored for billing calculations. For auditing and data fidelity purposes, Orb never overwrites or permanently deletes ingested usage data.
timestamp
of the new event must match the timestamp
of the existing event already ingested. As with
ingestion, all timestamps must be sent in ISO8601 format with UTC timezone offset.customer_id
or external_customer_id
of the new event must match the customer_id
or
external_customer_id
of the existing event already ingested. Exactly one of customer_id
and
external_customer_id
should be specified, and similar to ingestion, the ID must identify a Customer resource
within Orb. Unlike ingestion, for event amendment, we strictly enforce that the Customer must be in the Orb
system, even during the initial integration period. We do not allow updating the Customer
an event is
associated with.idempotency_key
with the event in this endpoint, since this request is by design
idempotent. On retryable errors, you should retry the request and assume the amendment operation has not
succeeded until receipt of a 2xx.timestamp
must fall within the customer’s current subscription’s billing period, or within the
grace period of the customer’s current subscription’s previous billing period.API Keys can be issued in the Orb's web application.
OK
The response is of type object
.
This endpoint is used to amend a single usage event with a given event_id
. event_id
refers to the
idempotency_key
passed in during ingestion. The event will maintain its existing event_id
after the amendment.
This endpoint will mark the existing event as ignored, and Orb will only use the new event passed in the body of
this request as the source of truth for that event_id
. Note that a single event can be amended any number of
times, so the same event can be overwritten in subsequent calls to this endpoint. Only a single event with a given
event_id
will be considered the source of truth at any given time.
This is a powerful and audit-safe mechanism to retroactively update a single event in cases where you need to:
This amendment API is always audit-safe. The process will still retain the original event, though it will be ignored for billing calculations. For auditing and data fidelity purposes, Orb never overwrites or permanently deletes ingested usage data.
timestamp
of the new event must match the timestamp
of the existing event already ingested. As with
ingestion, all timestamps must be sent in ISO8601 format with UTC timezone offset.customer_id
or external_customer_id
of the new event must match the customer_id
or
external_customer_id
of the existing event already ingested. Exactly one of customer_id
and
external_customer_id
should be specified, and similar to ingestion, the ID must identify a Customer resource
within Orb. Unlike ingestion, for event amendment, we strictly enforce that the Customer must be in the Orb
system, even during the initial integration period. We do not allow updating the Customer
an event is
associated with.idempotency_key
with the event in this endpoint, since this request is by design
idempotent. On retryable errors, you should retry the request and assume the amendment operation has not
succeeded until receipt of a 2xx.timestamp
must fall within the customer’s current subscription’s billing period, or within the
grace period of the customer’s current subscription’s previous billing period.API Keys can be issued in the Orb's web application.
OK
The response is of type object
.