# Changelog of UK Tenders Scraper: Contracts Finder & Find a Tender Notices (`yappman/contracts-lookup`) Actor

- **URL**: https://apify.com/yappman/contracts-lookup/changelog.md
- **Full Actor documentation**: https://apify.com/yappman/contracts-lookup.md

## Changelog

UK Public Contracts Lookup (`actors/contracts-lookup`). Newest first.

### Unreleased

- Alert mode takes `ocids`: 1 to 200 OCIDs, to send only the new notices of the procurements you track (exact match on the row's `ocid`, combined with any other filter; a repeated OCID counts once). The alert is otherwise unchanged: the same 14-day window, store, one send per notice, charges and digest, and a Contracts Finder amendment is still not sent again. `RUN_SUMMARY.ocids` gives `requested` and `matchedProcesses`. Find a Tender's older-regulations notices from its daily files have no OCID and cannot be tracked this way; one procurement can have different OCIDs on Find a Tender and Contracts Finder. All other modes refuse `ocids` before anything is read.

- Contracts Finder coverage in renewals, renewals alerts and buyer profiles is now taken over its expected days: weekdays that are not bank holidays in England and Wales, plus any weekend or bank-holiday day whose file was read. Contracts Finder publishes files for working days, so a weekend or bank-holiday day with no file no longer counts against the 85% minimum. A working day with no file still counts as missing, and so does a weekend or bank-holiday day whose file could not be read. `coverage.cf` keeps `daysInWindow` (calendar days) and adds `daysExpected` and `quietDaysWithoutFile`; `percentRead` is `daysRead` / `daysExpected`. Find a Tender, which publishes a file each day, is unchanged.

- When coverage is below 85%, the status message and `reason` give the shortfall in days, for example "Contracts Finder: 210 of 253 expected day files read (83.0%, 85% needed: 6 more days were needed)".

- In buyer profiles and the renewals modes, which read their daily files within a 25-minute limit, a daily file request that fails with a network error, a server error (5xx) or a "too many requests" answer (429) is tried once more after about 2 seconds (`bulkRetries` in `RUN_SUMMARY`). Search and alert do not retry. `bulkErrors` counts the requests that ended with neither a file nor a "no file for that day" answer (403 or 404): those that still failed after the retry where there is one, and any other answer such as 400. A day with no file is not retried.

### 0.1.21 (4 Nov 2026)

- Renewals, renewals alerts and buyer profiles read Find a Tender from its daily files for the whole look-back (12 months; 365 days for profiles).
- Renewals and renewals alerts read at most 12 months when Find a Tender is among the sources (the default). `lookbackMonths` still accepts 1 to 24, so saved Tasks keep working, but a value above 12 is then cut to 12 (a run with `"sources": ["cf"]` still reads up to 24 months): `RUN_SUMMARY.lookbackClampedFrom` gives the value asked for, and the status message says "Look-back cut from 24 to 12 months while Find a Tender is read from its daily files." This cuts Contracts Finder too: an existing renewals alert or saved Task set to 24 months on the default sources now reads 12 months of Contracts Finder as well, so a contract first published 13 to 24 months ago whose end date later moves into the window is not sent. To keep 24 months of Contracts Finder, use `"sources": ["cf"]` (Contracts Finder only). A Contracts Finder-only run of 24 months may not finish within the 25-minute limit: unread days then count as missing, and a renewals alert below 85% coverage sends nothing (this release has not measured that case). In a measured run, 12 months of both services' day files took about 17 minutes; 24 months did not finish within the 25-minute limit and fell below 85% coverage. Renewals uses Find a Tender's API only for today, and for yesterday until its file is out, and only for Procurement Act notices: an older-regulations notice is read from its daily file only (an API record is skipped and counted in `sources.fts.ftsLegacyFromApiSkipped`), so it reaches renewals a day later than a Procurement Act notice.
- New mode `pipeline`: planning notices (Find a Tender `UK1` to `UK3` and older prior information notices; Contracts Finder and, if chosen, Public Contracts Scotland planning notices), sorted by `futureNoticeDate`, soonest first. `expectedFrom` and `expectedTo` keep notices whose expected date falls on those UK days; otherwise it is a search, with the same window, filters, row and price.
- Two new fields on each notice row: `noticeType` (the Find a Tender Procurement Act form, `UK1` to `UK17`; `null` for older forms, Contracts Finder and Public Contracts Scotland) and `futureNoticeDate` (when the buyer expects its next notice, usually the tender; `null` where none is given).
- Search, alert, renewals and renewals alert refuse `expectedFrom` and `expectedTo` before anything is read; nothing is charged.
- Cost: one-off renewals runs now return about 12 months of Find a Tender rows instead of about 8 days, so more rows are charged at $0.02 each, up to `maxItems`. A buyer that publishes only on Find a Tender now gets a charged profile ($0.10) instead of a free "no notices". A profile run below 85% day-file coverage for either service makes no profile and is not charged. A renewals run with `"sources": ["fts"]` whose Find a Tender API gave no answer charges its rows but not the run fee (the run fee follows Contracts Finder day files read or API answers).
- A renewals alert created before this release does not send Find a Tender contracts whose notice was published before its first run of this release (more exactly, at or before the end of its last earlier run; `ftsFilesSince`). They are counted in `ftsBeforeAlertFloor` and not sent or charged. Start a new `alertId` to receive them. Contracts Finder rows are not affected. Because that time is the end of the last earlier run, Find a Tender notices published while that run was going (up to about 25 minutes) are left out too, and so are older-regulations notices published later that same day (their daily file gives the date only): never charging a contract twice is preferred to never missing one.
- Renewals rows from Find a Tender's older-regulations forms come from its daily files only, so they have `ocid` `null` and, as `publishedAt`, the UK publication date at midnight UTC (0.1.20 and earlier read them from the API, with an OCID and a time), and a renewals alert sends and charges such a notice once. Their end date is read only where the notice states one; a notice that states only a duration gives no row. An older-regulations award and its modification notice are now always separate rows, where 0.1.20 and earlier joined them by OCID; so a renewals alert sends and charges an older-regulations modification notice (F20) as a new row even when its dates equal the award's. For such a notice published between 00:00 and 01:00 UK summer time the shown `publishedAt` can be up to an hour later than the real time. A Find a Tender API release that names neither the Procurement Act nor an EU directive as its legal basis gives no renewals row from the API (counted in `ftsLegalBasisUnknown`); the next run reads it from its daily file. Two same-day versions of one such notice tie on `publishedAt` and release number (a Find a Tender release number is its notice id's year), so the first read is kept.
- Rolling back to 0.1.20 and then forward again can send and charge a second time a renewals-alert row from an older-regulations notice that has a stated end date and was published during the rollback: 0.1.20 and earlier identify such a notice by its OCID, this release by its notice id. Procurement Act notices are not affected.
- Buyer profiles and renewals need at least 85% of each service's day files (Contracts Finder and Find a Tender). Below it a profile is not made and nothing is charged, a renewals alert sends and charges nothing, and a one-off renewals run says it is incomplete.
- If renewals is switched back to reading Find a Tender from its API only (an internal switch, not an input), older-regulations notices are not read at all, and neither are API notices whose legal basis is not recognised (`ftsLegalBasisUnknown`).

### 0.1.20

- Find a Tender daily files that hold their notices inside a folder are read again. Find a Tender re-published at least two day files that way: the 28 Oct 2026 file, re-published around 2 to 3 Nov; and the file of one day between 4 and 14 Oct, re-published before 28 Oct. Until this release such a day gave no Find a Tender notices from its file: the run summary counted them in `sources.fts.skippedEntries`. Searches covering those days were missing them. An alert that had already read the day before it was re-published keeps what it sent and does not receive those notices again. An alert whose first run came after a day was re-published (for 28 Oct: created after about 06:45 UTC on 3 Nov) never received that day's notices; from this release it receives the matching ones on its next run, charged as new, as a late delivery, while the day is inside its 14-day window.

- If you searched 28 October 2026 or the affected October day between the re-publication and 4 November, run the search again to get the full results. Contracts Finder and Public Contracts Scotland were not affected, and nothing was charged for notices that were not returned.

### 0.1.13

- Find a Tender is read from its official daily files in search and alert modes; existing alerts do not receive a backlog of older Find a Tender notices — on their first run under 0.1.13 they only send notices published after their last run. That first run may also leave out Find a Tender notices that the earlier run held back for maxItems, could not read, or that were published around its last run: such notices can be missed, but no backlog is ever sent or charged.