Create Usage Reprice

Creates a reprice operation for a revocation request that has already reached a terminal state (completed or completed_with_errors). The operation clones each source raw event (incrementing revision) onto the ingest queue with pinned extractor (and optional pricing) versions. The processor rates and persists normally, then writebacks the target status via reprice_target_id metadata and closes the operation when the last target lands.

POST /v1/projects/:project_id/usage/events/reprice

Authentication

Authorization: Bearer <api-key>

Requires usage:reprice.

Path Parameters

Field	Required	Description
project_id	Yes	Project that owns the events.

Request Body

Field	Required	Description
revocation_id	Yes	Must reference a terminal (completed / completed_with_errors) revocation created with purpose=reprice.
extractor_rule_set_id	Yes	Extractor rule set pinned on the reprice ingest.
extractor_version	Yes	Extractor version pinned on the reprice ingest. Must be > 0 and reference a published version.
pricing_rule_set_id	No	Optional pinned fallback pricing rule set.
pricing_version	No	Required when pricing_rule_set_id is set.
reason	Yes	Human-readable reason.
business_request_id	No	External ticket / batch correlation ID.
idempotency_key	No	Tenant/project scoped create idempotency key.

Revocations that are still processing, or that ended failed, are rejected with an error: repricing while the original consumption stands would double-charge. Pinning a draft extractor version is also rejected with 400 reprice: pinned extractor version must be published: draft content is mutable, so only immutable published versions may be pinned.

Example

curl -X POST 'http://127.0.0.1:8080/v1/projects/proj_gateway/usage/events/reprice' \
  -H 'Authorization: Bearer <api-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "revocation_id": "urv_reprice_001",
    "extractor_rule_set_id": "ers_new",
    "extractor_version": 3,
    "pricing_rule_set_id": "prs_new",
    "pricing_version": 2,
    "reason": "old token price was incorrect",
    "idempotency_key": "reprice-batch-001-v2"
  }'

Response

202 Accepted

{
  "reprice_id": "urp_001",
  "status": "enqueueing",
  "requested_count": 0
}

The operation is durable before the worker queue publish is attempted. If the queue publish fails, the API still returns 202 with "status": "enqueue_failed"; the operation exists and can be re-published via the retry endpoint (or by re-sending this request with the same idempotency_key).

requested_count is filled after revocation targets are materialized. Poll the get/list-targets endpoints for per-event progress. Targets expose both new_raw_event_id (set when ingest is published) and new_raw_event_id (set asynchronously when the processor finishes).