First call GET /addresses with a postcode, let the user choose from candidates, then send the selected candidate's id as property_id here. No intervening POST /lookups or schedule download is needed. The selected address must already have a usable saved schedule. If the postcode response cannot offer property_id choices, follow the ordinary lookup flow for the council's required input instead.

A read-only lookup of an existing public calendar. Supply exactly one identifier form: uprn, property_id, or gss plus council_id. No other query parameters, repeated parameters or written addresses are accepted. The identity must resolve uniquely, and its saved schedule must pass the existing date and cache-usability gates. Provisional, undated and postcode-representative results cannot supply a link here. This operation never discovers addresses, contacts a council, creates a lookup or queues a refresh, even for stale or missing schedules. Public feeds must be enabled. The URL is the one a Schedule's calendar_url names for the same property: a verified UPRN, either the property's own or the one verified UPRN its UPRN-shaped council identifier maps to under the same GSS; otherwise the council's property identifier. A URL that would not resolve uniquely is refused.

The separate allowance is 100 requests per rolling 24 hours per anonymous network (IPv4 address or IPv6 /64), or per bearer token. Successful and unsuccessful reads, including HEAD, consume it; ordinary read allowance is not consumed. The preceding GET /addresses uses the standard address-discovery allowance. Outer traffic protections still apply. Like other request quotas this is process-local and resets on restart; the boundary minute is conservatively retained. Responses use no-store. Save a successful URL for subscription; calendar fetches have their own existing behaviour and read limits.