Madrid Protocol

The Madrid Protocol is an international treaty that allows trademark holders to seek protection in multiple countries through a single application filed with WIPO (the World Intellectual Property Organization). Signa models the Madrid System, including international registrations, designations, coverage status, and Madrid-specific deadlines.

How the Madrid System Works

Filing: The applicant files an international application through their home office (the “office of origin”)
WIPO registration: WIPO registers the mark in the International Register and publishes it in the Madrid Gazette
Designation: The applicant designates one or more member countries where they want protection
National examination: Each designated office examines the mark under its own law
Protection or refusal: Each office independently grants or refuses protection

Data Model

Signa models a Madrid IR as one designation record per designated country, plus the IR record itself (the international registration). Each designation is an independent trademark that can have its own status, deadlines, and events, because each designated office makes independent decisions about examination, opposition, and renewal. A mark can be protected in one country and refused in another.

Designation

Field	Value
`filing_route`	`madrid_designation`
`office_code`	`WO` (always: every WIPO-sourced record uses the WIPO office code)
`jurisdiction_code`	The designated country (e.g., `GB`, `DE`): tracks where protection is sought
`scope_kind`	`international_registration`
`ir_number`	The WIPO registration number (links all designations from the same IR)

Querying an IR family

GET/POST /v1/trademarks defaults to grouped result presentation (international_registrations=grouped): a Madrid IR family is returned as one row with a coverage rollup summarizing every designated territory’s status. Pass international_registrations=expanded to get one row per designation instead. Either way, GET /v1/trademarks?ir_number=... returns the whole family, and GET /v1/trademarks/{id} on the IR parent returns the same rollup with the full per-territory breakdown inline (below). A designation that Signa has not linked to its IR parent record is the exception: the grouped view returns it as its own row with coverage: null, so an ir_number search can return several grouped rows for one IR. A grouped request that carries a filter the grouped view can’t apply is answered with expanded rows instead: search_meta.international_registrations reads expanded and search_meta.fallback_reason names the filter. Expanded rows have no coverage, and total_count counts designations, not marks. jurisdictions always stays grouped, and it is the filter for “IRs designating this country”. offices and filing_route stay grouped when they are the only filter; combined with another filter they fall back. Known limitation: a text query (q, q_any, mark_text_not_contains) on the grouped view is matched against the IR family’s mark text, while offices or filing_route matches any record in the family. A linked national record whose mark text differs from its IR can therefore put a family in the results even though its record at that office carries different text. Designations share the IR’s mark text, so only linked national records are affected. Use international_registrations=expanded when you need the text and the office matched on the same record. offices matches the office a record comes from, so offices=CA finds CIPO records, not every IR designating Canada. The per-designation date filters (filing_date_*, registration_date_*, expiry_date_*) still fall back. See international_registrations for the full list.

Querying Madrid Marks

Find All Madrid Marks

# All Madrid designations
curl -s "https://api.signa.so/v1/trademarks?filing_route=madrid_designation" \
  -H "Authorization: Bearer sig_YOUR_KEY"

// All Madrid designations
const madridMarks = await signa.trademarks.list({
  filing_route: "madrid_designation",
});

// Shorthand: the is_madrid filter
const madridMarks2 = await signa.trademarks.list({
  is_madrid: true,
});

Find by IR Number

The ir_number is globally unique and does not require an office parameter:

curl -s "https://api.signa.so/v1/trademarks?ir_number=1234567" \
  -H "Authorization: Bearer sig_YOUR_KEY"

const marks = await signa.trademarks.list({
  ir_number: "1234567",
});
// Returns the IR family (grouped, by default) or every designation (expanded)

Coverage Territories

Retrieving an IR parent returns every designated territory inline under coverage. There is no separate coverage fetch: coverage.territories[] carries the full per-territory breakdown, and coverage.by_primary / coverage.by_stage give you the rollup counts. coverage is null on an individual designation leg and on direct or regional marks, which cover exactly one territory.

curl -s "https://api.signa.so/v1/trademarks/tm_abc123" \
  -H "Authorization: Bearer sig_YOUR_KEY" | jq '.coverage.territories[]'

const mark = await signa.trademarks.retrieve("tm_abc123");
for (const territory of mark.coverage?.territories ?? []) {
  console.log(
    territory.territory,
    territory.protection_status,
    territory.protection_date,
    territory.trademark_id, // the designation record covering this territory
  );
}

Each entry also carries territory_name, designation_date, refusal_date, status_effective_date, is_subsequent_designation, designation_protocol, and source_records[] (the WIPO/national reconciliation alternates for a dual-feed territory). Coverage status values:

Status	Meaning
`designated`	Designation filed, examination pending
`provisionally_refused`	Office issued a provisional refusal
`finally_refused`	Protection definitively refused
`protected`	Protection granted
`withdrawn`	Designation withdrawn by the holder
`renounced`	Holder renounced protection in this territory
`ceased`	Protection ceased (e.g., central attack)
`invalidated`	Protection invalidated
`limited`	Goods/services limited in this territory
`expired`	Protection expired (not renewed)

Madrid-Specific Dates

Madrid marks carry additional date fields beyond the standard trademark dates:

Field	Description
`designation_date`	When the designation was filed at WIPO
`protection_effective_date`	When protection took effect in the designated territory. Null until the office reports it.
`dependency_period_end_date`	End of the 5-year dependency period tied to the base application. Currently null; derive it yourself as `intl_registration_date` + 5 years if you need it today.
`transformation_deadline_date`	Deadline to transform a cancelled designation into a national application. Currently null; derive it yourself as the central attack date + 3 months if you need it today.

The Dependency Period

For the first 5 years after international registration, a Madrid mark depends on its base application/registration at the office of origin. If the base mark is cancelled, refused, or surrendered during this period (a “central attack”), the international registration can be cancelled for all designated territories.

Transformation

If an international registration is cancelled due to a central attack, the holder can “transform” each designation into an independent national application within 3 months.

Madrid-Specific Deadlines

The deadline engine handles Madrid marks differently from domestic marks. Key differences:

Aspect	Domestic	Madrid
Renewal	Filed at the national office	Filed at WIPO (centralized)
US proof of use	Section 8 (domestic)	Section 71 (Madrid equivalent)
Trigger date	Varies by jurisdiction	`protection_grant_date` (US), `intl_registration_date` (WIPO)

WIPO Renewal

International registrations are renewed centrally at WIPO every 10 years from the international registration date. This covers all designated territories at once.

Field	Value
Type	`international_renewal`
Trigger	`intl_registration_date`
Cycle	Every 10 years
Consequence	`lapse_of_international_registration`

Relationships

GET /v1/trademarks/{id} returns mark-to-mark links inline as relationships[]:

Relationship Type	Meaning
`based_on_basic_application`	The IR is based on this national application
`based_on_basic_registration`	The IR is based on this national registration
`transformed_from`	This national mark was transformed from a cancelled IR designation
`replaces_under_4bis`	Replacement under Madrid Protocol Article 4bis

The IR-to-designation link is not repeated here: it is coverage.territories[].trademark_id on the parent. trademark_id on a relationship is null when the counterpart is not a record Signa holds, which is the normal case for based_on_basic_* edges (the office reports them as a bare office code plus record number). Identify those by target_office_code and target_record_id.

curl -s "https://api.signa.so/v1/trademarks/tm_abc123" \
  -H "Authorization: Bearer sig_YOUR_KEY" | jq '.relationships[]'

const mark = await signa.trademarks.retrieve("tm_abc123");
for (const rel of mark.relationships) {
  console.log(rel.type, rel.direction, rel.trademark_id ?? `${rel.target_office_code}:${rel.target_record_id}`);
}

Getting started

Core concepts

Build with AI

Data

Monitoring

Working with the API

Use cases

How the Madrid System Works

Data Model

Designation

Querying an IR family

Querying Madrid Marks

Find All Madrid Marks

Find by IR Number

Coverage Territories

Madrid-Specific Dates

The Dependency Period

Transformation

Madrid-Specific Deadlines

WIPO Renewal

Relationships

​How the Madrid System Works

​Data Model

​Designation

​Querying an IR family

​Querying Madrid Marks

​Find All Madrid Marks

​Find by IR Number

​Coverage Territories

​Madrid-Specific Dates

​The Dependency Period

​Transformation

​Madrid-Specific Deadlines

​WIPO Renewal

​Relationships

How the Madrid System Works

Data Model

Designation

Querying an IR family

Querying Madrid Marks

Find All Madrid Marks

Find by IR Number

Coverage Territories

Madrid-Specific Dates

The Dependency Period

Transformation

Madrid-Specific Deadlines

WIPO Renewal

Relationships