LEI Renewal Monitor API

What this Actor returns

Give it a list of counterparty LEIs (Legal Entity Identifiers) and it returns one row per LEI it finds in the open LEI index: where each registration stands, when it is next due for renewal, and which ones have lapsed, are due for renewal, are no longer valid, need your attention, or changed since a date you choose. Every row has the same 15 fields, and a value the record does not have is null, never a missing key.

• lei, legal_entity_label, entity_category: the identifier, the registered legal name and the kind of entity
• registration_status, entity_status, successor_lei: the state of the LEI registration and of the entity, and the LEI that replaces it where the index names one
• next_renewal_date, last_update_date: when the registration is next due and when its record was last updated
• lapsed, renewal_due, no_longer_valid, needs_attention, updated_since: five flags that are computed by this tool from the index's own fields; they are not GLEIF data
• changes_since: with a change date, the index's own change entries since then (field, old value, new value and date), each entry written out as JSON text; entries that contain an email address or phone number are left out
• changes_status: ok when the change history was read, unavailable when the index could not be reached for that LEI, not requested when you gave no change date

The Actor reads the open LEI index API and nothing else: no other source and no enrichment. It does not scrape any website, and there is no login. It keeps nothing between runs, so to see what changed, give the date of your last check.

Who it helps

• Compliance, onboarding and finance teams, who hold a list of counterparty LEIs and want to know which registrations have lapsed, are close to their renewal date, or are no longer valid because they were retired, merged or annulled.
• Data and operations teams who keep LEIs in a spreadsheet or database and want a scheduled check of what changed since the last run, through the Apify API.

Quick start

1. Open the Input tab and leave the defaults as they are. They check three long-lived LEIs, so a first run returns exactly three rows.
2. Press Start. The default run costs about $0.00905: 3 rows at $0.003 is $0.009, plus Apify's tiny run-start event (see What it costs). Try it on these three first.
3. Open the Output tab, check the rows, then replace the LEIs with your own list, set how far ahead you want renewals flagged, and add a change date if you want to see what changed.

Input

Field	What it does	Default
LEIs to check (leis)	The counterparty LEIs, one 20-character code per entry, up to 100. Case and spaces around a code do not matter, and a code given twice is checked once.	three long-lived LEIs
Renewal due within (renewalWithinDays)	An issued LEI is flagged renewal_due when its next renewal date is today, within this many days, or already past. From 0 to 730.	60
Changed since (changedSince)	Optional, written YYYY-MM-DD. Fills updated_since and changes_since. Leave empty to skip it.	empty
Maximum rows (maxItems)	The most rows to return and pay for, from 1 to 100. It must be at least the number of valid LEIs you give; if it is lower the run stops with a clear message before checking anything.	10

Each code is checked against the ISO 17442 checksum first. A code that fails is named in the run log and is neither looked up nor charged. A code that passes but is not in the index is named in the run log too, and is not charged either. The run's final status message counts both.

Output

One row per LEI found, in the order you gave them. The rows below are what the default input returned on 13 October 2026, unchanged.

[
  {
    "lei": "5493001KJTIIGC8Y1R12",
    "legal_entity_label": "Bloomberg Finance L.P.",
    "entity_category": "GENERAL",
    "registration_status": "ISSUED",
    "entity_status": "ACTIVE",
    "next_renewal_date": "2027-01-25",
    "last_update_date": "2026-01-05",
    "successor_lei": null,
    "lapsed": false,
    "renewal_due": false,
    "no_longer_valid": false,
    "needs_attention": false,
    "updated_since": null,
    "changes_since": null,
    "changes_status": "not requested"
  },
  {
    "lei": "HWUPKR0MPOU8FGXBT394",
    "legal_entity_label": "Apple Inc.",
    "entity_category": "GENERAL",
    "registration_status": "ISSUED",
    "entity_status": "ACTIVE",
    "next_renewal_date": "2027-03-08",
    "last_update_date": "2026-03-03",
    "successor_lei": null,
    "lapsed": false,
    "renewal_due": false,
    "no_longer_valid": false,
    "needs_attention": false,
    "updated_since": null,
    "changes_since": null,
    "changes_status": "not requested"
  },
  {
    "lei": "INR2EJN1ERAN0W5ZP974",
    "legal_entity_label": "MICROSOFT CORPORATION",
    "entity_category": "GENERAL",
    "registration_status": "ISSUED",
    "entity_status": "ACTIVE",
    "next_renewal_date": "2027-05-04",
    "last_update_date": "2026-04-07",
    "successor_lei": null,
    "lapsed": false,
    "renewal_due": false,
    "no_longer_valid": false,
    "needs_attention": false,
    "updated_since": null,
    "changes_since": null,
    "changes_status": "not requested"
  }
]

How the five flags are computed, from the index's own fields:

• lapsed is true when registration_status is LAPSED.
• renewal_due is true when registration_status is ISSUED and next_renewal_date is today, within renewalWithinDays days, or already past. It is false for any other status, and null when the renewal date is missing.
• no_longer_valid is true when registration_status is RETIRED, MERGED, ANNULLED, DUPLICATE, CANCELLED or PENDING_ARCHIVAL, or entity_status is INACTIVE. TRANSFERRED and PENDING_TRANSFER only move the LEI to another issuer, so they do not count.
• needs_attention is false only when registration_status is ISSUED, entity_status is ACTIVE and renewal_due is false. It is true for anything else, including a status this tool does not recognise and a missing renewal date, so a record is never shown as clear by mistake. Filter on it for a quick list of what to look at.
• updated_since is true when last_update_date is on or after changedSince. It is null when you gave no date.

With changedSince, each row also lists the index's own change entries dated on or after that date, each one written out as JSON text with the index's names: recordType, modificationType, field, date, valueOld (the old value), valueNew (the new value) and context. Entries that contain an email address or phone number are left out. An empty list means nothing changed. If the history of one LEI cannot be read, that row still comes back with all its flags, changes_since is null and changes_status is unavailable; run it again for that LEI. For example, this input:

{
  "leis": [
    "INR2EJN1ERAN0W5ZP974",
    "EXAMPLE0000000009981",
    "5493001KJTIIGC8Y1R13"
  ],
  "renewalWithinDays": 365,
  "changedSince": "2026-04-01"
}

returned this row. It is what that input returned on 13 October 2026, unchanged. The other two LEIs gave no rows: one fails the checksum and one is not in the index. They are named in the run log and were not charged.

{
  "lei": "INR2EJN1ERAN0W5ZP974",
  "legal_entity_label": "MICROSOFT CORPORATION",
  "entity_category": "GENERAL",
  "registration_status": "ISSUED",
  "entity_status": "ACTIVE",
  "next_renewal_date": "2027-05-04",
  "last_update_date": "2026-04-07",
  "successor_lei": null,
  "lapsed": false,
  "renewal_due": true,
  "no_longer_valid": false,
  "needs_attention": true,
  "updated_since": true,
  "changes_since": [
    "{\"recordType\": \"LEI\", \"modificationType\": \"UPDATE\", \"field\": \"/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Registration/lei:NextRenewalDate\", \"date\": \"2026-04-08T00:00:00Z\", \"valueOld\": \"2026-05-04T00:00:00Z\", \"valueNew\": \"2027-05-04T00:00:00Z\", \"context\": null}",
    "{\"recordType\": \"LEI\", \"modificationType\": \"UPDATE\", \"field\": \"/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Registration/lei:LastUpdateDate\", \"date\": \"2026-04-08T00:00:00Z\", \"valueOld\": \"2025-03-28T08:58:24.047Z\", \"valueNew\": \"2026-04-07T09:26:31.880Z\", \"context\": null}"
  ],
  "changes_status": "ok"
}

What it costs

You pay for one event, LEI checked, at $0.003 per row returned. Apify also adds its standard run-start event, $0.00005 per start for an Actor run with up to 1 GB of memory; it is the platform's own event, not ours. The default run of 3 rows costs about $0.00905. Checking the history for a change date does not cost extra. A row whose history could not be read (changes_status unavailable) is still charged, because its status check worked. Invalid LEIs, LEIs not in the index and rows the Actor leaves out (see below) are never charged.

For example, a list of 100 valid LEIs that are all found costs $0.30 plus the start event. If your Apify plan includes monthly credit, a small run draws on that credit.

If the source cannot be reached or keeps answering with errors, the run stops with a clear status message, and only the rows already returned are charged.

Limits and honest notes

• Up to 100 LEIs per run. The source's documented limit is 60 requests per minute. The Actor sends at most one request every two seconds, half of that, and looks LEIs up 50 to a request, so a list of 100 takes 2 requests. With a change date it also asks for each LEI's history, one request per LEI and up to 3 per LEI for a very long history, so a full run of 100 is at most 302 requests. At two seconds each that is 604 seconds, about 10 minutes, plus the source's own answer time. The platform's default run timeout is one hour, so a full run has several times that margin when the source is healthy. Longer lists: split them over several runs.
• Pace and busy source. When the source is busy it waits as asked, up to about a minute per request, and then stops with a clear message.
• The flags are this tool's reading of the index's fields. They are not GLEIF data. no_longer_valid and needs_attention read the registration status, the entity status and renewal_due; successor_lei is filled only where the index names a successor.
• A change is dated by the index. It can be dated a day after the last_update_date of the same update, so a row can show updated_since true on a date where changes_since is empty, or the other way round, at the edge of the date you chose.
• Long histories are cut. For one LEI the Actor reads at most the first 600 history entries; if the history is longer, the cut is written to the run log. Entries that hold an email address or a phone number are left out of changes_since.
• A history that fails. If the index keeps refusing one LEI's history after the Actor's retries, that row is still returned and charged with changes_since null and changes_status unavailable, and the run log names the LEI. If the main lookup fails, the run stops with a clear message as before.
• The history covers every record of the LEI, not only its registration: relationship and reporting-exception records are included, each marked by its recordType.
• No sole proprietors. A sole proprietor is a natural person, so the Actor leaves those records out. It also leaves out any record whose name holds an email address or a phone number, and any record with no name or registration status.
• What it does not do. No search by name, no ownership or parent links, no addresses, no other source, and nothing stored between runs.
• Freshness follows the source. last_update_date is the date the LEI record was last updated at the source.

Questions

Why did my run return fewer rows than I gave LEIs? Some LEIs failed the checksum, were not in the index, or were left out because they are sole proprietors or lacked a name or a registration status. The final status message counts each reason and the run log names the LEIs. You were not charged for those.

What does the run say when something is wrong? It says what it found and what to try. "Give at least one LEI in leis" means the list was empty. "You gave 25 LEIs but maxItems is 10" means raise maxItems so no LEI is left unchecked. A message about changedSince or renewalWithinDays shows the right shape. "Could not be reached" or "kept answering" means the source is busy; wait a few minutes and run again.

What does needs_attention mean? It is false only for an issued registration of an active entity that is not due for renewal inside your window. Anything else is true, so a lapsed, retired, merged, annulled or inactive record, a renewal that is due, and a status the tool does not recognise all show up.

What does a lapsed registration mean? LAPSED means the entity did not renew its LEI in time. The record is still in the index, so you can see its dates, and lapsed is true.

How do I see what changed since my last check? Set changedSince to the date of your last check. Rows then say whether the record was updated since, and list the changes the index recorded. Run it on a schedule with the Apify scheduler or the API; each run is independent and charged per row.

Why is renewal_due true for an LEI that is still issued? Its next renewal date is today, inside your window, or already past while the index still shows it as ISSUED. Raise or lower renewalWithinDays to move the window.

Data source and AI note

Data source: the GLEIF LEI Index (the Global LEI Index), released under the CC0 1.0 public-domain licence. The index's fields are output as the source gives them. The five flags are computed by this tool from those fields and are not GLEIF data. There is no other source and no enrichment. last_update_date is the date the record was last updated at the source, taken from its lastUpdateDate field; the rows have no source_updated_at field.

This tool is not affiliated with, endorsed by or sponsored by GLEIF or any Local Operating Unit.

This tool was built with the help of AI coding assistants.

Help

Questions, a row that looks wrong, or an idea for a field: please open an issue on the Issues tab. Thank you for the report; every one is read.