Curations

Eg:cur-9Fw3RtYxQ7nLpK

A curation is a user-submitted correction to a native entity — a fact you’re telling OpenAlex it got wrong. OpenAlex mints its native entities by inference: it disambiguates authors from raw name strings, reads affiliations off works, decides which work 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 “About” 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 and two that fix the names on an author 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.

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 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.

Attributes

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 for how each field is built.

id

String. The curation’s ID, e.g. cur-9Fw3RtYxQ7nLpK. Unlike native-entity OpenAlex IDs, it is not a resolvable openalex.org URL.

user_id

String. The ID of the user who submitted the curation, e.g. user-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 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 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. For the full list of endpoints see the endpoints index.