Skip to main content
POST
Reconcile
Credits: 1 per item.

Overview

Compare the trademark records you already hold against Signa’s register data and get a field-by-field diff back. Nothing is stored. Records drift from the register over time: statuses change, owners change, registration numbers get assigned, and renewal dates move. Send the fields you have and Signa tells you, per record and per field, exactly where you still match the register and where you’ve fallen out of sync. Use it to surface exceptions, run scheduled drift checks, or audit a book of matters during onboarding. Records that aren’t found, or that match more than one register entry, come back as per-item outcomes in the response, never a request-level error.

Request Body

object[]
required
Records to reconcile, max 100 items. Results are returned in the same order, with one reconciliation per input item.
boolean
default:"false"
Opt in to the three-source per-field verdict. Each found item gains field_verdicts[], a computed context block and a lookup echo. Everything v1 is unchanged: fields[], result, mismatch_count, and billing are identical with the flag on and off. Required to send your_fields.docketed_deadlines.

Response

A standard list response with data: Reconciliation[]. Pagination is not used; data[i] corresponds to items[i].
string
Always list.
object[]
boolean
Always false.
object
Always { "cursor": null }.
string
Unique request identifier for support and debugging.
not_found is soft: the request still returns HTTP 200, with result: "not_found" for that item and an empty fields array. ambiguous means the identifier lookup resolved to more than one register record, such as an (office, application_number) pair that is not unique; Signa does not silently choose one.

Three-source verdicts (verdict_detail)

Send verdict_detail: true to turn a drift check into a docket audit. For every field you supply, Signa compares three sources: your value, the register’s value, and the value Signa’s deadline rulebook computes for the same mark (the same computation GET /v1/trademarks/{id} serves under derived.deadlines, with missed obligations included and a 10-year horizon that extends per record, up to 20 years, so the schedule always reaches the register’s stated expiry).
Enabling the flag changes nothing you already rely on. fields[], result and mismatch_count are byte-identical with the flag on and off, and billing is unchanged (1 credit per item). A verdict where you are right and the register or the rulebook disagrees never flips result to mismatch.
Each field_verdicts[] entry carries field, your_value, register_value, computed_value, basis, verdict, computed_unavailable_reason, and computed_provenance (the rule_id, effective_from, last_verified, due_date_adjustment, grace_expiry_adjustment and holiday_calendar behind the computed date, spelled exactly as the deadlines API spells them). Rows for docketed_deadlines entries use field: "docketed_deadline" with sibling deadline_type and index (your array position); both are null on the nine standard field rows. For expiry_date, computed_value is the term end before any weekend or holiday roll, the same date derived.expiry_date serves. For renewal_due_date and docketed deadlines it is the due date after the roll, the date the office accepts a filing on. A value on either date counts as agreement.

A docketed-only request always reads match

Send a your_fields that contains only docketed_deadlines and the item comes back with result: "match", an empty fields[] and mismatch_count: 0. That is the designed outcome. v1 semantics are frozen: result, fields[] and mismatch_count describe the nine standard fields and nothing else, so a docketed deadline can never move any of them. The audit you asked for lives exclusively in field_verdicts[] and verdict_counts{}, with one row per deadline you sent. Read the verdicts rather than result.

basis: which sources answered

When the computed side produced nothing, computed_unavailable_reason says why: not_modelled (the rulebook has no concept of this field, true for everything except expiry_date, renewal_due_date and docketed deadlines), unsupported_jurisdiction (no rulebook coverage for this record’s jurisdiction and route), or insufficient_data (coverage exists but the record lacks the statutory input, or no matching obligation was emitted).

The seven verdicts

Two behaviors worth knowing:
  • unsupported_jurisdiction and insufficient_data are verdicts only when the register is also silent. When the register did answer, the verdict describes that comparison (agrees or caller_differs) and the computed-side gap is reported on computed_unavailable_reason instead. Nothing is hidden; the verdict names the comparison that actually happened.
  • not_computable also fires for a register-only field whose column is empty, for example mark_text on a device mark.

How the computed value is chosen

For expiry_date and renewal_due_date, the computed counterpart is the mark’s current term end: the earliest computed renewal-family obligation due on or after today, falling back to the most recent past one (the cycle currently in force). The rulebook treats expiry and renewal-due as one date under two names. When the office-stated expiry, its grace period and any restoration window have passed with no renewal on record, no later cycle is computed, so the counterpart is that past term end, the same date as derived.expiry_date (see The term on record). For docketed_deadlines entries, matching is deliberately about the obligation you docketed: within your entry’s type, the occurrence whose due date is nearest your date wins (ties go to the earlier one). A docketed renewal matches the whole renewal family, including a US combined Section 8 and 9 filing and a WIPO international renewal. The matched rule is echoed in computed_provenance.rule_id so the pairing is checkable.

Identifier matching

lookup.identifier_normalization is none today: the identifiers you send are matched as sent, with no trimming, leading-zero handling or separator stripping, except Madrid registration numbers, which also match the stored WO-prefixed and zero-padded forms (see registration_number above). The echo exists so office-specific normalization can ship later without a shape change. lookup.matched_on shows which identifiers were combined into the lookup, which also explains ambiguous results when you sent both.

Code Examples