# Curations

A **curation** is a user-submitted correction to a [native entity](/entities/native/) — a fact you're telling OpenAlex it got wrong. OpenAlex mints its native entities by inference: it [disambiguates authors](/entities/authors/#how-we-build-it) from raw name strings, reads [affiliations](/entities/raw-affiliation-strings/) off works, decides which [work](/entities/works/) each authorship belongs to. That inference is sometimes wrong, and a curation is how you push back on it: *this authorship is mine*, *that work isn't mine*, *my name should be displayed like this*. Each curation records **who** changed **what**, **when**, and its review state — and, once applied, flows into the entity it corrects. A curation's ID looks like `cur-9Fw3RtYxQ7nLpK`.

## Who creates it, what states it moves through, and how it flows back

Curations come from users, not from the pipeline, so they have no "How we build it" provenance story. Instead:

### What you can curate

Curation today centers on **author corrections** — the entities most prone to disambiguation error. Four corrections are available, two that fix the authors attributed to a [work](/entities/works/) and two that fix the names on an [author](/entities/authors/) profile:

- **`claim work`** — assign a misattributed authorship on a work to your author profile.
- **`remove from work`** — detach a work that isn't yours from your profile.
- **`modify display_name`** — change the displayed name on your author profile.
- **`modify full_name`** — change the name used to *match future works* to your profile.

The mechanics — exact request bodies, the `property` anchor syntax, and how each action maps to a warehouse table — are documented in [Author curation](/api/author-curation/).

### Who can file one

Curations are recorded against the signed-in OpenAlex user account that submits them. Two kinds of user can curate:

- **Claim owners** — a user who has claimed an author profile can curate *that* profile (and the works on it). Claim-owner edits that add works are rate-limited (1,000/day).
- **Site-wide curators and organization owners/curators** — users with site-wide access can curate **any** author with no claim ownership, and are uncapped. Other authenticated users who are neither get a `403`.

Every curation row carries the submitting `user_id`, so the audit trail of "who claimed what" is preserved even though it isn't surfaced on the public read API.

### The states it moves through

A curation is submitted, reviewed, and then either applied to the live data or not:

1. **Submitted.** The request lands as one row with `is_applied: false` and `applied_at: null`. Submitting the same curation twice (same user, entity, entity_id, value, action) returns the existing row rather than creating a duplicate, so re-submitting is idempotent.
2. **Reviewed and applied.** Curations are picked up on the next end-to-end refresh of the pipeline, which runs once per day — so an accepted change should appear within about 24 hours. When a curation is applied, its `is_applied` flips to `true` and `applied_at` records the time.

Because curations are re-applied *every* cycle, an accepted correction is **sticky**: a removed author stays removed even if the automated matcher tries to re-attach it on a later run.

### How an accepted curation flows into the entity

An applied curation rewrites the native entity it targets:

- A **work claim** overwrites the author on the matching authorship, so the work now appears on the claimed [author](/entities/authors/) profile.
- A **work removal** clears the author from that authorship, so the work drops off the profile.
- A **display_name** change overwrites the profile's displayed name and re-syncs the author's works so the new name shows up in the API.
- A **full_name** change updates the name the matcher uses, steering how *future* works are attributed.

Every curated work is queued to re-export to the search index on the next sync, so the correction propagates to search results, not just the entity object. For the step-by-step data flow (Postgres → per-type views → warehouse Delta tables → the live entity tables), see [Author curation](/api/author-curation/#how-it-flows-under-the-hood).

## Fields

A curation record is a compact statement of a correction: the target entity, the property to change, the change itself, and its review state. The shape below is what the curation endpoint returns; see [Author curation](/api/author-curation/) for how each field is built.

### `id`
*String.* The curation's ID, e.g. `cur-9Fw3RtYxQ7nLpK`. Unlike native-entity [OpenAlex IDs](/entities/common-fields/#id), it is not a resolvable `openalex.org` URL.

### `user_id`
*String.* The ID of the user who submitted the curation, e.g. `usr-abc123`. This is the audit trail of who made the correction; it's stored on every row but not exposed on the public read API.

### `user_name`
*String.* The display name of the submitting user, e.g. `Casey M`.

### `entity`
*String.* Which native entity type the curation corrects — `works` (for claim / remove actions) or `authors` (for display_name / full_name actions).

### `entity_id`
*String.* The OpenAlex ID of the specific entity being corrected, as a full URL, e.g. `https://openalex.org/W4404012345` for a work claim or `https://openalex.org/A5023888391` for a name change.

### `property`
*String.* The field on the target entity that the curation changes. For work claims this anchors the change to a specific byline — `authorships[raw_author_name="Smith, J."].author.id` — pinning the correction to one raw author name from the work. For work removals it's the non-positional `authorships.author.id`. For name changes it's simply `display_name` or `full_name`.

### `action`
*String.* What to do with the property — `replace` (claim a work, set a name) or `remove` (detach a work).

### `value`
*String.* The new value the action applies, as a full URL where it's an entity (the author ID for a claim or removal) or a plain string for a name change (`John Smith`).

### `created`
*String.* The [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) datetime the curation was submitted.

### `is_applied`
*Boolean.* Whether the curation has been applied to the live entity data. Starts `false` on submission and flips to `true` once a pipeline run applies it.

### `applied_at`
*String.* The [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) datetime the curation was applied, or `null` while it's still pending.

## In the API

Curations are submitted to `POST https://user.openalex.org/curations` — note the singular `user.` host — authenticated with your OpenAlex API key in the `Authorization: Bearer` header. The endpoint accepts a single JSON object or an array of them. Site curators and organization owners/curators can curate any author; a claim owner can curate their own claimed profile; other authenticated users get a `403`. For the complete request shapes, the `property` anchor rules, and the under-the-hood data flow, see [Author curation](/api/author-curation/). For the full list of endpoints see the [endpoints index](/api/endpoints/).