Skip to main content
GET
List Deadline Rules

​
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. 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 plus WIPO). Comma-separated for multiple values, e.g. ?jurisdiction=US,EU,GB.
​
string
Filter by filing route. Accepted values: national, regional, madrid. 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

Five jurisdictions (GB, SG, IS, JP, 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, 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[] always anchor window_opens on the renewal’s grace expiry. That is exact for grace_expiry rules (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 null), so no field is silently omitted. Because applies_to is null, restoration rows match every filing_route filter value, exactly like any other unscoped rule. They are filtered normally by jurisdiction.

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

​
Errors