Acquisitions

The properties your organisation is pursuing to buy: from first look through teaser, IM, data room and bid to bought, lost or parked.

An acquisition is one property your organisation is pursuing to buy. Some are your own — a property you found, a lead from a contact. Others follow a teaser or a Case Room invitation an advisor sent you: Propstreet records one when you answer the teaser, and keeps it linked to that teaser while the advisor keeps it open to you.

Acquisitions belong to your organisation: every member reads and changes them, and no other organisation ever sees them. They are for verified investors; a broker's token answers 403. On the Free plan your organisation pursues at most ten open acquisitions of its own at a time (parked ones and those that follow an advisor's teaser do not count): one more — or reopening a closed or parked one — is refused with 403 and the problem type /help/plan-required, and closing (as bought, lost or parked) or deleting one in the app makes room (see Errors & Retries).

Quick Reference

How Acquisitions Work

Own lead ───────────────┐
                        ├──▶ Acquisition ── stage: not_contacted → teaser → im → data_room → bid
Advisor's teaser ───────┘         │
  (answered or Case Room          ├── outcome: open → won | lost | parked   (reopen brings it back to open)
   invitation accepted)           ├── property     one of your property records (propertyId)
                                  ├── currentOwner a contact or company of your Relationships
                                  ├── connection   how it stands with the advisor: none | connected | disconnected | inactive
                                  └── notes, tasks its history

• Two stages. stage is the stage your organisation set. shownStage is what the app shows: on an acquisition that follows a teaser, what has happened since — contact established, NDA signed, Case Room access — raises it. A bid is always set by you.
• The advisor stays anonymous until disclosed. connection.advisorName is present only once the advisor's identity is disclosed to your organisation, exactly as in the app. origin carries what the teaser itself discloses — its title, locality and property types. Both are null for a member of your organisation the teaser or Case Room does not let in (for example a colleague never invited to that room).
• One open acquisition per property. Creating an acquisition for a property you already pursue answers 409 with the existing id in acquisitionId; creating one for a property whose acquisition is closed opens that one again.
• Closing. POST .../{id}/close with outcome won (bought), lost or parked. Won needs a property; the property becomes one of your own and, with comp, the purchase is recorded as a comp with your organisation as buyer and the seller — and, on an acquisition that follows an advisor's teaser whose advisor may be named to you, that advisor as the seller's advisor — once contact is established the broker is added to your network under the advisor's company when not there yet (Professional plan). On an acquisition that follows an advisor's teaser, won closes the teaser too, lost closes it unless closeTeaser is false, parked leaves it as it is.
• Ending the advisor link. PATCH with "keepAdvisorLink": false keeps the acquisition as your own and ends its link to the teaser; it cannot be set again.

Sync

GET /api/v1/acquisitions?updated_since=2026-11-01T00:00:00Z&include_deleted=true&page_size=100

The list is in the order acquisitions last changed, oldest first, with page.nextCursor to continue. updated_since is the parameter every v1 list takes, so the same sync code serves acquisitions too.

What moves updatedUtc:

• a change to the acquisition's own fields, its stage, its close and its reopen;
• on an acquisition that follows an advisor's teaser, a change on the teaser's side that changes what the acquisition shows: you answer the teaser, disconnect from it or connect to it again; the advisor establishes contact or declines it, closes the teaser or removes your seat in the Case Room; the project is closed, deleted, restored or handed to another advisor; the Case Room ends; the NDA is signed or Case Room access is granted (connection, connection.inactiveReason, connection.advisorName and shownStage). The ETag moves with it, so a PATCH sent with an older If-Match answers 412: read the acquisition again and retry.

A note or a task does not move updatedUtc — subscribe to the acquisition.* webhooks for those. With include_deleted, a deleted acquisition comes back with deletedUtc. Clocks differ: re-read with an updated_since a few minutes before your newest updatedUtc and treat an acquisition you already hold as an update. See Sync Patterns.

Writes

POST /api/v1/acquisitions
Idempotency-Key: 7d1f6c2e-0b9a-4b52-9e3e-2f1d5a8c4e10
Content-Type: application/json

{ "name": "Kv. Hamnen 2", "propertyId": "1042", "stage": "teaser", "interest": "interested" }

Answers 201 with the acquisition, its ETag and Location. Send the ETag as If-Match with the next PATCH, close or reopen; a stale one answers 412. Without If-Match the change applies to the acquisition as it is now. A field you leave out of a PATCH keeps its value; null clears it (stage and responsibleUserId cannot be cleared).

POST /api/v1/acquisitions/381/close
If-Match: "AAAAAAAAB9E="
Content-Type: application/json

{ "outcome": "won", "comp": { "dealDate": "2026-11-15", "price": 182000000 } }

Acquisitions are deleted in the app, not over this API: close or park one here instead. A deletion done in the app cannot be undone; it lists the acquisition with deletedUtc in the delta sync and sends acquisition.deleted.

Webhooks

Every row of an acquisition's history is one event, delivered to the webhooks of your organisation that subscribe to it. The payload names ids and changed fields only, never the advisor. acquisition.updated carries changed_fields with the public field names (name, responsible, currentOwner, propertyId, connection); acquisition.task_added and acquisition.task_completed carry task_id. Your own disconnect and reconnect send acquisition.updated naming connection; a change on the advisor's side sends no event — it moves updatedUtc, so the delta sync picks it up. Once an acquisition is deleted, no further event is sent for it. See Webhooks.

MCP

The MCP server offers the same acquisitions to an investor's agent: list_acquisitions, get_acquisition, create_acquisition, update_acquisition, close_acquisition (with preview), reopen_acquisition, add_acquisition_note and add_acquisition_task. See MCP Server.