Change requests & review

Every item you push through POST /patents/sync becomes a change request: a durable record of what you sent, what differed from the live patent, and how it ended. The requestId in each per-item result is the id of that record; quote it in support requests. This page explains the triage model behind the outcome field, so you can interpret every response your sync loop receives.

The reason this model exists: Renewr's patent data drives real payments to patent offices. A wrong filing date or office code recomputes renewal deadlines, and a missed deadline can kill a patent. So the sync channel never lets a deadline-shaping change flow straight through: harmless changes apply immediately, everything else waits for a Renewr reviewer to confirm it.

The five outcomes

outcome	What happened	What your integration should do
APPLIED	The change was safe and is live	Nothing; a re-read reflects it immediately
STAGED	The change awaits review	Wait; re-poll the batch later for the decision
ACCEPTED	A reviewer accepted a staged change; it is live	Nothing; for a creation, read the new patent's UUID from renewrPatentId
REJECTED	The item was invalid, or a reviewer refused it	Read reason, fix the data at the source, push again
SUPPRESSED	An identical re-push of an already refused change	Stop re-sending it unchanged; fix the data first

Two timing rules complete the picture:

• Triage never produces ACCEPTED. Review happens after triage, on human time: a first POST of a batch only answers APPLIED, STAGED, REJECTED or SUPPRESSED, and ACCEPTED appears when you poll GET /patents/sync/{importId} later. One caveat: a replayed POST (same externalImportRef, same items; see safe retries) returns the batch's current state, so it can carry ACCEPTED for items a reviewer has decided since the original POST. Handle all five outcomes wherever you read a response body.
• STAGED is not final. The same item reads ACCEPTED or REJECTED on a later poll of the same batch. The batch-level stagedItems counter, in contrast, is frozen at triage and never decreases; it answers "how many went to review", never "how many are still waiting".

What applies immediately, what goes to review

On an update, Renewr first diffs your item against the live patent, field by field, on real differences only: re-sending the full record when one field changed produces a one-field diff, and a deep comparison means a reordered array does not count as a change. An update whose diff is empty is APPLIED as a no-op, without writing anything.

The diff then decides the route:

• Non-critical changes apply immediately: titles, your case and family references, owner display names, claim counts, and similar descriptive data.
• Critical changes are staged: any field that can re-drive the renewal computation. Think of the office, the patent's status and type, the filing route, and the legal dates (filing, grant, publication, expiration, lapse, and the date renewals are managed from).
• Patent numbers are always staged: a change to applicationNumber, publicationNumber, grantPublicationNumber or pctApplicationNumber goes to review whatever the office, because the office-standard form Renewr maintains from them may need re-deriving. See the numbers section of the push guide.
• Creations are always staged. A new patent means new renewal events and new payment obligations; that is a human decision by design.

Which fields count as critical is configured per office on the Renewr side. For an office with no explicit configuration, the default is the full set of renewal-driving fields listed above: office, status, type, route and the legal dates all stage, while descriptive changes (titles, references, owner names, claim counts) still apply immediately. So expect the exact boundary between APPLIED and STAGED to vary by office and to be tuned over time; expect date, status, office, type and number changes to stage everywhere. Code your loop against the outcome you receive rather than a hardcoded field list.

A staged change blocks nothing

STAGED puts the proposal in a queue; the live patent keeps its current values and every read keeps working. You do not need to pause your sync while items await review.

Review decisions

A Renewr reviewer sees your staged proposal next to the live values and decides, per proposal, all or nothing:

• Accepted: the change is applied (or the patent is created). The item reads ACCEPTED on your next poll, and an accepted creation now carries the new renewrPatentId.
• Refused: the item reads REJECTED, and reason carries the reviewer's explanation verbatim. This is the same field that carries validation reasons at triage time; after review it is a human sentence written for you.

There is no partial acceptance of an item. If a reviewer refuses a five-field proposal because one field is wrong, the whole proposal is refused; fix the field and push the item again.

Refusals feed an anti-spam filter

A refused proposal leaves a fingerprint. If your integration pushes the same change to the same patent again, unchanged, the item comes back SUPPRESSED: it is not re-staged, and no reviewer sees it a second time. This protects the review queue from a mirror that re-exports its state on a schedule and would otherwise re-submit every refused change forever.

The way out is always the same: read the refusal reason, correct the data in your IPMS, and let the corrected record flow out with your next push. A corrected proposal fingerprints differently, so it is a new proposal and gets staged normally. This holds for numbers too: a refused number change re-pushed with a fixed number is new, never suppressed.

REJECTED covers two situations

An item invalid at triage (bad date format, unknown enum value, missing identity) and a proposal refused by a reviewer both read REJECTED. Distinguish them by timing and by reason: triage rejections are immediate and mechanical (Invalid item: …, Forbidden field: …), review refusals appear on a later poll with a human explanation.

Newer wins: superseding and ordering

Renewr keeps at most one pending proposal per target: patent for updates, your providerId for creations. When a new push targets something that already has a staged proposal, the older proposal is marked superseded and drops out of the review queue; only the newest is ever decided. Even a no-op update supersedes: if your latest push shows the source aligned with the live patent, an older pending proposal is obsolete by definition.

Two consequences worth designing for:

• The latest batch is the authoritative view. In an old batch, a superseded item keeps reading STAGED forever; the item's story continued in a newer batch. When reconciling, trust the most recent import that touched a patent, and treat older batches as history.
• There is no ordering between concurrent pushes. Renewr applies "last arrived wins" between two pushes of the same patent; nothing in the payload says which export is fresher. Run one exporter at a time per portfolio, in commit order of your source. Two concurrent exporters can interleave and land an older state on top of a newer one.

What the sync never does

Boundaries that keep the model predictable:

• No office verification. Renewr does not check your proposal against the office's public records; review is a plausibility check by an operator, and the only automatic acceptance is the non-critical route. Data quality remains your side's responsibility.
• No decisions through the API. Accepting or refusing staged changes is a Renewr-side workflow; the API gives you the resulting outcomes.
• No writes to officialNumbers. The office-standard numbers are maintained by Renewr operators; the sync channel rejects any attempt to set them.
• Patents only. Trademarks have no push channel today.

Related pages

• Pushing your portfolio: the endpoint mechanics, identity matching, idempotence
• Synchronize your IPMS with Renewr: the push-poll-reconcile loop, ready to adapt
• Keeping data in sync: mirroring Renewr data back, the read half
• Errors: per-item outcomes versus HTTP errors, and the conflict code