---
title: "Re-trigger validation or ingestion for a roster job"
method: PUT
path: "/roster/republish-event/{eventType}"
tags: ["Roster"]
---

# Re-trigger validation or ingestion for a roster job

`PUT /roster/republish-event/{eventType}`

Queues the validation or ingestion stage again for a roster job that already exists.

**When to use:** call this as a recovery step when a roster has stalled because its processing event was lost, and you need to nudge the pipeline without creating a new job. To submit a corrected file instead, use `PUT /roster/{rosterId}/reupload`.

**Preconditions:** supply the `tenant-id` header and set `eventType` in the path to either `validation` or `ingestion`; the value is matched case-insensitively and anything else is rejected with 400. The request body must carry `rosterId`, identifying an existing roster job. Only `rosterId` is read from the body - the tenant is taken from the header, and the acting user from the roster's own record, so any `tenantId` or `userId` sent in the body is ignored.

**State guard:** the stage must still be meaningful for the job. Re-queuing `validation` on a roster that is already `VALIDATED`, or `ingestion` on one that is already `COMPLETED`, is rejected with 400 naming the current status rather than silently doing nothing.

**What you get back:** a short confirmation object echoing the event type that was queued. The work itself runs in the background, so poll the roster job to observe progress.

**Side effects:** a processing event is queued. Not idempotent while the roster remains in a re-processable state - repeated calls queue repeated runs.

## Path parameters

- `eventType` string, required

## Headers

- `tenant-id` string, required

## Request body

- object

## Response `200`

Confirmation that the requested stage was queued for the roster job.

- RepublishRosterEventResponse — Confirmation that a validation or ingestion event was queued again for the roster job.
  - `message` string — Human-readable confirmation that the event was queued.
  - `eventType` string — The processing stage that was queued, echoing the request path value.

## Other responses

- `400` — Returned when `eventType` is neither `validation` nor `ingestion`, when `rosterId` is missing from the body, when no roster with that id exists, or when the roster has already passed the stage being re-queued.
- `401` — Returned when the request carries no valid authentication.
- `500` — Returned when the event could not be queued. Retry; if the failure persists, contact support.

---

[API](https://skmtc.dev/certifyos/apis/certify-api-layer.md) · [All operations](https://skmtc.dev/certifyos/apis/certify-api-layer/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/certifyos/certify-api-layer/revisions/563848e0ecc0/schema)