28 October 2026 · Open API 1.10.0

Main feature - Ability to power your websites from the V2 API, and some smaller changes throughout the API for consistency

Website enquiries and valuation requests

Websites can now send leads into Loop through V2. This replaces V1's viewing, call-back, information and seller enquiry endpoints.

• POST /v2/sales/enquiries and POST /v2/lettings/enquiries, with type set to viewing, callBack or information.
• POST /v2/sales/valuation-requests, for a seller asking for a valuation, and GET /v2/sales/valuation-requests/{id}.
• Scope: all three need the new write:enquiries scope. Existing keys don't have it; ask us to add it to your key.
• Fields: they use the same names as the matching GET returns. Send the listing id (salesLifecycleListingId or lettingsLifecycleListingId), as V1 did.
• Preferred times: preferredTimes takes up to three ISO 8601 times. They're written into the enquiry's comment in UK time, alongside the request type.
• Property details: a valuation request can also include propertyType and bedrooms. These are added to the request's comment, so the agent sees them with the rest of the details.
• Response: a successful call answers 201 Created with the full enquiry and a Location header. A 400 lists each problem under the field it's about.
• Side effects: the agency gets the same alert, automatic reply and phone notification as for a portal lead. Your request never fails because one of those does.

{
  "salesLifecycleListingId": 99120,
  "type": "viewing",
  "firstName": "Sam",
  "lastName": "Example",
  "emailAddress": "[email protected]",
  "preferredTimes": ["2026-11-07T10:00:00Z"]
}

A guide to moving from V1 to V2 follows separately.

Website listings

• GET /v2/website/sales/properties: sales search for a website, the V2 copy of network.api's GET api/sales-properties. Results have the same fields with the same names, plus teamName (the property's office), and the filters are the same, except that limit replaces fetch, teamIds (team ids) replaces teamAPIList (other teams' keys), and results come in V2's { data, pagination }, with total.
• GET /v2/website/sales/properties/{id}: one sales property for a website's property page, the V2 copy of network.api's GET api/sales-properties/{lifecycleId}, with the same fields and names, plus teamName. Unlike network.api, it returns only properties listed on the website; any other answers 404.
• GET /v2/website/lettings/properties: lettings search for a website, the V2 copy of network.api's GET api/lettings-properties, with the same fields, filters and differences as the sales search. Without webListingStatuses, it shows properties to let and let agreed, or to let alone with excludeUnderOffer.
• GET /v2/website/lettings/properties/{id}: one lettings property for a website's property page, the V2 copy of network.api's GET api/lettings-properties/{lifecycleId}, with the same fields and names, plus teamName. As with the sales detail, only properties listed on the website are returned; any other answers 404.
• GET /v2/website/teams and GET /v2/website/teams/{id}: the offices your key covers, replacing V1's GET team. A client or network key gets all its active teams. Each team has V1's fields, plus id, clientId, its active agents as members, and its prospecting and matching outcodes for routing a lead by postcode. Either website scope opens it. Unlike V1, members leaves out agents who've left, and the brand colours are filled in (V1 always returned them as null).
• Enum values are names, as everywhere in V2: webMarketingStatus is "forSale", not a number, and sortOrder takes mostRecentlyAdded.
• New scopes: read:sales-website and read:lettings-website, for the website listing endpoints under /v2/website/. Existing keys don't have them; ask us to add them to your key.
• One step for a website's key: we can set up a key with everything a website needs: both of these, read:commercial-website and write:enquiries.

Residential properties

• Address: GET /v2/sales/properties and GET /v2/lettings/properties, list and detail, now return an address. Its parts are primaryNameOrNumber, secondaryNameOrNumber, street, locality, district, townOrCity, county, postcode, displayAddress and shortAddress. A part that isn't recorded is null.
• Responsible agent: responsibleAgentId and links.responsibleAgent are on both.
• Sales team: sales properties now include teamId and links.team, as lettings already did.
• Seller: sales properties now include sellerGroupId and links.seller, as lettings already has landlordGroupId and links.landlord.
• Service level: the lettings list now includes rentalServiceLevel.
• New filters on both lists: teamId, clientId and responsibleAgentId.

{
  "id": 13034,
  "teamId": "…",
  "responsibleAgentId": "…",
  "sellerGroupId": 8338,
  "address": {
    "primaryNameOrNumber": "12",
    "street": "Example Road",
    "townOrCity": "Harrogate",
    "postcode": "HG1 1AA",
    "displayAddress": "Example Road, Harrogate",
    …
  },
  "links": {
    "team": "/v2/teams/…",
    "responsibleAgent": "/v2/users/…",
    "seller": "/v2/sellers/8338",
    …
  },
  …
}

Tenancies

• Dates: GET /v2/lettings/tenancies and its detail now return dateCreated and dateUpdated. dateUpdated moves when the tenancy or one of its terms changes.
• Older tenancies: those created before this release carry dates taken from their history.
• updated_since: a new filter that collects only the tenancies changed since your last sync.
• Notices: noticeGivenDate and noticeServedDate. A tenant's notice is cleared if they later say they're not moving out.
• End of term: endOfTermStatus (unknown, renew or moveOut) on the list and the detail. unknown includes a tenant who has said they're not moving out after all.
• On the list: deposit.

Notes and documents on tenancies

tenancy is now a record type for notes and documents, so you can attach deposit certificates and inventories to a tenancy:

{ "entityType": "tenancy", "entityId": 51234, "noteText": "Deposit protected, certificate attached." }

Changed

• Swagger: the documentation at api.loop.software/swagger now opens on V2.