Skip to main content
GET
List Deadline Rules
Credits: 10 per request.

​
Overview

Returns a flat list of maintenance deadline rules (renewal cycles, declarations of use, incontestability filings, and similar) across every modeled jurisdiction. Each rule is self-contained: it carries its parent jurisdiction’s renewal_period_years and statutory sources, so you do not need a separate parent fetch to render a rule. Every field the engine reads is published here. Alongside the core rule shape, each row carries the era and mechanic fields: trigger_fallback, window_change_date / window_before, term_counts_trigger_day, month_end_overflow, renewal_window_end_of_month_until, first_renewal_after_cutoff_opens_at_period_start, term_schedule and the rest, which is what makes a computed row reproducible from the catalog. Each is documented with the office that uses it; the common case is the neutral value (null, false, or last_day). This endpoint exposes the same rule corpus that powers Compute Deadlines and the derived.deadlines block on a trademark detail response. Use it to build educational UI, validate deadline computations client-side, or show statutory citations alongside an alert. Every rule carries a rule_id, and every computed deadline row reports the rule_id that produced it, so any date Signa returns can be resolved back to the rule and citations behind it. Rules are not versioned one by one, and there is no rule-change webhook. To detect a change, keep the response’s ETag and send it back in If-None-Match: 304 means no rule in your filtered set changed. On a trademark, derived.ruleset_version changes whenever a rule that could affect a schedule changes. Rule changes are announced in the changelog. Two related vocabularies appear on this endpoint, and they are distinct:
  • Filing routes (the filing_route query parameter): national, regional, madrid. This is how a mark was filed.
  • Rule scope tags (the applies_to response field): domestic, madrid_only, all, or null. This is which filings a rule covers. domestic covers the national and regional routes, madrid_only covers the madrid route, and all or null covers every route.

​
Query Parameters

​
string
Filter by jurisdiction code: uppercase ISO-2, EU, and WO for the Madrid rules (WIPO is still accepted as an alias of WO). madrid_designation_renewal, the rule a Madrid designation of a jurisdiction without its own rules (a code WIPO designates) and of the EU is served, is listed once under WO and is also returned for every code it serves, e.g. ?jurisdiction=RU; a code WIPO does not designate (UK, ZZ) returns no rules. Comma-separated for multiple values, e.g. ?jurisdiction=US,EU,GB.
​
string
Filter by filing route. Accepted values: national, regional, madrid. Four trademark filing_route values are also accepted: direct_national reads as national, direct_regional as regional, and madrid_ir and madrid_designation as madrid. The other trademark values (transformation, divisional, unknown) return 400 with the accepted list. Comma-separated for multiple values.A rule passes the filter when its applies_to scope covers the requested route: domestic rules pass for national or regional, madrid_only rules pass for madrid, and all or null rules pass for any value. Multiple values union the matching sets.

​
Response

A standard list response with data: DeadlineRule[]. Pagination is not used: the corpus is small and returned in a single page, in a fixed, stable order. This endpoint is publicly cacheable, so the response never includes request_id. The list is one flat object type. Maintenance rules and restoration rules are both object: "deadline_rule" and are told apart by type, so a client can render the whole catalog with one code path.
​
string
Always list
​
object[]
​
boolean
Always false, no pagination
​
object
Standard pagination envelope (cursor: null)

​
Restoration rules

EU, GB, SG, IS, JP and IN model a restoration window: a last-resort filing that can revive a registration after the renewal grace period has already expired. Those rules are part of this catalog, as type: "restoration" rows, so every rule_id the compute engine can emit is resolvable here. A restoration row is the same flat deadline_rule object as any other, with three differences worth reading carefully:
  • due_year names the renewal cycle the restoration rescues, not a restoration due date. The restoration window itself is window_months months long, anchored as described below.
  • starts_from records the statutory anchor, not the anchor Signa computes from. The statute names either the end of the late-renewal period (grace_expiry: the EU, Iceland, Japan and India) or the date the registration was removed from the register (removal_date, UK and Singapore). Removal is an office act that happens after grace expiry and is not carried on a trademark record, so computed restoration rows on Compute Deadlines and in derived.deadlines.items[] always anchor window_opens on the renewal’s grace expiry. That is exact for grace_expiry rules (EU, IS, JP, IN) and a deliberately conservative approximation for removal_date rules (GB, SG), matching UKIPO’s published practice of removing six months after the renewal date. Do not compute removal_date + window_months from your own removal data and expect it to match: it lands later than Signa’s due_date by the removal lag, and Signa can under-report at the close of the window by that same lag.
  • grace_period_months is always 0. Restoration has no grace period of its own; it is the grace of last resort.
The maintenance-only fields are still present and truthful on these rows (earliest_filing_year and earliest_filing_months_before are null, recurring is false, optional is false, applies_to is the scope of the renewal the remedy rescues), so no field is silently omitted. Every restoration row’s applies_to is domestic: a Madrid designation renews only at WIPO, and the national restoration remedies do not reach it, so filing_route=madrid returns no restoration row. Before October 10, 2026 only eu_restitutio was domestic and the others were null. An unscoped row matches every filing_route filter value. Restoration rows are filtered normally by jurisdiction.

​
Post-registration response rule

The US catalog includes one row of type: "post_registration_oa_response", rule_id: "uspto_post_registration_oa_response": the response to a USPTO post-registration office action on a Section 8, Section 71 or combined Section 8 and 9 filing. It is the same flat object as any other row:
  • trigger is post_registration_action, the date of the office action, and due_year is 0, because the rule runs from an action rather than a term year.
  • window_months is 6. The response is due six months after the action, or at the end of the filing period the action examined if that is later (37 CFR 2.163(b), 2.184(b)(1), 7.39(a)). grace_period_months is 0.
  • consequence_if_missed is cancellation. A computed row carries the consequence of the filing it examined, so a response on a combined renewal reads cancellation_and_expiration.
See USPTO post-registration office actions for when the row is served and what closes it.

​
Ordering

The catalog is returned in a fixed order: jurisdiction configurations in registry order, each config’s maintenance rules in rule order, and that config’s restoration row (when it has one) immediately after its maintenance rules. The US post-registration response row follows the US domestic rules. The order is stable across deploys and cache fills, so you can rely on it, but rule_id is the identity to key on, not the position.

​
Code Examples