Property & Unit Mapping
Configure externalId values during Getting Started — Recommended Setup Sequence step 13 — Listings property wizard and each unit’s Channels tab — before any partner GET /listings or POST /bookings. Complete steps 11–12 (Integrations, Integration field capability, Tenant categories default for integrations) so channel credentials and payload fields match your mapping plan. Finish steps 14–15 and Onboarding a New Property — Step 7 to confirm mapped IDs appear in operator UI before escalating sync defects. Guide pairing after go-live: Setup sequence after go-live (hub: API Reference — Setup sequence after go-live).
Start with How Mapping Works and Mapping Setup in the operator UI, then Verifying Your Mappings before partner traffic. Confirm externalId values in Listings & Availability before POST /bookings in Creating Bookings. Full-feed paths also require landlordKey resolution — see Full listing feeds (Which listings appear). Habit-specific shortcuts live under Related below.
Every listing on your platform must be mapped to the corresponding listing (unit) in Vivin. This mapping is what allows Vivin to know which unit a booking belongs to when you submit it via the API.
How Mapping Works
GET /listings returns your externalId on each row — verify against Listings & Availability before POST /bookings.
Each mapping is stored as a Listing Integration record in Vivin, which links:
| Your Side | Vivin Side |
|---|---|
Your platform's listing ID (externalId) | A Vivin listing (unit) |
| Your platform name | The integration platform identifier |
When you call GET /listings, the externalId in each listing response is your ID - the one your platform uses to identify that unit. That pull only includes units with a Channels mapping and that are still Included in feed for your platform. A unit marked Excluded from feed on Integration listings is omitted even when a mapping exists. The full catalogue can include unlinked units keyed by the Vivin listing id — Which listings appear.
When you submit a booking via POST /bookings, you send the externalId and Vivin looks up the corresponding Vivin listing to create the booking on the correct unit.
Kiwi, Capital Rooms, Porta85, and Lisbeyond single-landlord feeds return every listing on the provisioned account. Units without a channel link still appear — externalId is the Vivin listing UUID and listingInternalName carries the unit’s internal name. You can POST /bookings with that UUID. Details: API Reference — Kiwi, Capital Rooms, Porta85 & Lisbeyond.
Uniplaces inbound bookings do not send {landlordKey} on the webhook URL. Store the full-feed reference_id and echo it as offer_api_reference. That value is your channel externalId when the unit is linked, or the Vivin listing id when it is not. See Webhooks & Notifications — Uniplaces and Full listing feeds — reference_id.
Housing Anywhere inbound bookings do send {landlordKey} on the webhook URL — the stored landlord key or the Housing Anywhere integration email, same as the full feed. Store the full-feed listingReference and echo it as listing_external_reference. That value is your channel externalId when the unit is linked, or the Vivin listing id when it is not. See Webhooks & Notifications — Housing Anywhere and Full listing feeds — listingReference.
Inlife stores the channel key as propertyId_roomId. The full feed splits it into listing id (property) and room.id (room) — both underscore-free. Partial GET /listings and POST /bookings still use the joined string. See Full listing feeds — Inlife id and room.id.
externalId in SwaggerIn Integration Swagger, GET /listings/{propertyId} (by Vivin property id) returns listings with the externalId your platform must send on booking create. See Listings availability for the workflow screenshot.

Mapping Setup
Operators save externalId on each unit Channels row — see Settings > Integrations and Sales → Channel Manager.
Mapping is configured in the Vivin management dashboard by the property manager:
- Settings > Integrations - Enable your integration platform
- Listings > Channels Tab - For each listing, the property manager enters the external ID that corresponds to the listing on your platform
- Once mapped, the listing appears in your
GET /listingsresponse. Until then it can still appear onGET …/listings/fullkeyed by the Vivin listing id.
Operators link each unit to your platform from the unit sidebar Channels section (after account credentials are enabled in Settings). The externalId you send on POST /bookings must match the value saved on that row:

For account-wide platform toggles and credentials, see Settings > Integrations. For day-to-day sync status across many units, use Sales > Channel Manager.
The property manager creates the mapping in Vivin's UI, not the integrating platform. During onboarding, coordinate with the property manager to ensure every listing they want to distribute through your platform has the correct external ID configured.
Mapping Data Model
Full-feed landlordKey scoping reuses the same account linkage — see Full listing feeds — landlordKey. Field matrix: Integration field capabilities.
┌──────────────────────┐ ┌──────────────────────┐
│ Your Platform │ │ Vivin │
│ │ │ │
│ Listing ID: "R-42" │ ──────► │ Listing: Studio 3A │
│ │ maps │ Property: Casa Sol │
│ │ to │ Account: Acme PM │
└──────────────────────┘ └──────────────────────┘
Each mapping record contains:
| Field | Description |
|---|---|
externalId | Your platform's listing identifier |
integrationPlatform | Your platform name (e.g. housinganywhere, uniplaces) |
listingId | The Vivin listing UUID |
accountId | The Vivin account (property manager) UUID |
link | (Optional) URL to the listing on your platform |
Studio / Single-Unit Properties
Some properties in Vivin are studios or single-unit properties where the property itself is the bookable unit. In these cases, the externalId may correspond to either:
- The full listing reference (for Inlife,
propertyId_roomIdfrom/house/{propertyId}/{roomId}) - Just the property reference (for Inlife,
propertyIdfrom a studio URL/house/{propertyId})
When Inlife or the Vivin Booking Engine stored only the property id, a booking that arrives with propertyId_roomId still matches that row. Prefer storing the full pair when the listing URL includes both segments. See Full listing feeds — Inlife id and room.id.
Verifying Your Mappings
Authorize with Authentication before your first verification GET /listings. Missing rows map to 404 on booking create — see Error Handling.
After the property manager has configured the mappings, verify them by calling:
GET /{platform}-integration/listings HTTP/1.1
Authorization: Bearer YOUR_API_KEY
Every listing that appears in the response has a valid mapping and a usable positive rent. If a listing you expect is missing:
- The external ID may not be configured in Vivin
- The listing may not be active (deleted or not yet published)
- The listing may not have a usable positive rent — a €0 fixed amount, or a variable grid with any zero month, omits the unit from both pulls (
GET /listings/{externalId}then returns404Listing not available) — Listings & Availability — Usable rent required - The unit may be Excluded from feed for your platform — Integration listings
Multiple Platforms
One Vivin unit can map to HousingAnywhere, Spotahome, and your platform at once — operator context in Integrations & Distribution. Calendar-only partners use iCal feeds instead of JSON externalId pulls.
A single Vivin listing can be mapped to multiple external platforms simultaneously. This is how Vivin acts as a central distribution hub - one unit can be listed on HousingAnywhere, Spotahome, Uniplaces, and your platform at the same time, with availability synchronised across all of them.
Each mapping is unique per platform. A single listing cannot have two different external IDs for the same platform.
Property & Unit Mapping section cross-reference
Use the endpoints and fields above. Related integrator pages are linked inline where useful.
Related
Related below links externalId and landlordKey mapping to setup, companion API guides, operator workflows, and escalation paths.
Setup sequence after go-live
Complete Account Settings — Recommended setup order before partner traffic.
- Setup steps 1–10 — Complete operator workspace basics (Recommended setup order) before requesting partner Bearer keys; property managers automating outside the browser use Management session authentication after step 3 (Users)
- Setup steps 11–12 (Integrations, Integration field capability, Tenant categories default for integrations) — Channel credentials, calendar horizons, and payload field expectations before
[email protected]onboarding; operator context: Integrations & Distribution - Setup step 13 (Listings) — Property wizard,
externalIdmapping, and Channels tab before first partner listing reads or writes - Setup steps 14–15 (Bookings, Tenants) — Validate imported reservation shape and tenant segments after partner traffic
- After steps 13–15 — Onboarding a New Property — Step 7 go-live verification before escalating partner pull, webhook, or mapping defects
- During step 13 — save each unit
externalIdon Listings — Channels tab before partnerGET /listingsorPOST /bookingslookups succeed - Partner credential requests — Email
[email protected](distinct from in-app Vivin support tickets in Get Help & Support)
Documentation map & escalation
- Getting Started — Recommended Setup Sequence before partner HTTP traffic;
- API Reference hub — Hub pairing matrix across integration guides;
- Get Help & Support — Request credentials or mapping onboarding via
[email protected](hub: Setup sequence after go-live) - FAQ & Troubleshooting — Operator mapping and channel sync questions (hub: Setup sequence after go-live)
- Integration field capabilities — Operator-facing field matrix per marketplace
Companion API guides
Companion guides share Bearer authorization or error shapes with this page — start from API Reference hub.
- Listings & Availability —
externalIdon eachListingDtorow in partial pulls - Creating Bookings —
externalIdin the booking submission body - Full listing feeds — Partner-shaped catalogue exports that reuse the same mappings (unlinked units still appear there — Which listings appear)
- iCal feeds — Calendar retrofeed URLs that reuse the same unit rows as partial pulls
- Booking Lifecycle & Validations — Post-submit pipeline after partner
POST /bookingsreferences a mappedexternalId - Webhooks & Notifications — Push callbacks when mapped units receive bookings or calendar updates
- Error Handling —
404on unknownexternalIdduring mapping verification before first partner traffic - Booking Engine API — White-label engine IDs and
PUT /listingupdates - Authentication — Bearer token required before verification
GET /listings - Management session — Operator JWT contrast when internal scripts poll account-scoped routes after mapping verification
- AI usage — Internal LLM token ledger on the same management JWT (not integration Bearer keys)
Upstream & downstream workflows
- Onboarding a New Property — Property wizard Step 5 channel connections after mappings exist
- Processing a New Booking — Operator confirmation after mapped
POST /bookingssucceeds - Manual block hygiene — Portfolio pass when mapped units look fully blocked in partial pulls
- Notification triage — Clear import- or mapping-related alerts after verifying Channels linkage
- Managing a Check-out & Deposit Refund — Unit mapping context when deposit rows open the wrong listing sidebar during triage
- Portfolio KPI review — Reconcile imported booking volume after first authorized partner traffic
Operator UI & settings
- Settings > Integrations — Operator connection UI where platform credentials are provisioned alongside account setup
- Listings — Channels tab — Operator UI where platform external IDs are saved per unit
- Sales → Channel Manager — Day-to-day sync status across many units
- Settings > Owners — Landlord records assigned before property external IDs go live
- Settings > Preferences — In-app notifications — Account-wide mapping or import alerts after verifying Channels linkage
- Settings > Emails — Lifecycle templates that append Access Lockers codes after mapping is complete
- Property & listing details (booking engine) — Rich catalogue operators edit after
externalIdmapping succeeds on Channels - Create New — Property and Unit — Inventory wizards before mapping external IDs on Channels
Deeper concept reads
- Integrations & Distribution — How operators enable platforms before your token can see listings
- Payment Allocation — Two-layer receipts, invoiced-floor rent edits, and credit note reject/revert warnings
- Booking Lifecycle — Computed Upcoming → Ongoing → Ended / Canceled status model, list filters, and Timeline
- Tenant Portal — Mapped units determine which property-scoped portal modules and services tenants see
- FAQ — Tenant contract signing blocked — No PDF yet, mandatory Your Details gates, category locks, or Lease purpose; portal signing vs paper upload on Contract Info
Deeper workflow reads
See Upstream & downstream workflows above for the same guides.
Operator habit hubs
Day-to-day operator habits (lockout catch-up, pending receipts, payment triage, handoffs, and related playbooks) live on the Common Workflows habit hub.
Deep-link anchors for habit hubs
Lockout catch-up after password recovery
Pending manual receipt approval
Reject/revert mistaken receipts
Portfolio segmentation by tenant category
Notification row-click navigation
Payment alert to receivables triage
Confirmation alert triage
Finance debt receivables triage
Handling a Late Payment collections
Finance Income status drill-down
Cash flow forecast drill-down
Key glossary terms
- Glossary — Credit note (payment reject/revert) — Accounting follow-up when partner booking payments need reject/revert on Transactions
- Glossary — Deposit lifecycle status —
externalIdmaps imported bookings to units; deposit collection follows listing deposit configuration after enqueue - Glossary — End-of-Booking cost split — Charge Time → End of Booking splits daily overage across every occupied unit; still-staying roommates stay in the denominator
- Glossary — Change history — Operator-initiated edits on Listings setup and Bookings Changelog; create-time defaults excluded
- Glossary — Archived booking ledger visibility — Delete Booking hides manual/provider_platform rows on Finance → Transactions; vIBAN and credit card stay visible
- Glossary — Finance tenant category cache refresh — Recategorizing a tenant updates
booking.tenantCategoryIdimmediately; ledger tabs reflect it on reload, while Overview can lag up to ~10 minutes - Glossary — Full term list
Module documentation hubs
for screen-by-screen operator follow-up.
- Audit module — Manual blocks on mapped units that still appear in
unavailabilitiespulls (hub) - Bookings module — Operator reconciliation when mapping alerts or import duplicates appear (hub)
- Dashboard module — KPI snapshot when mapping gaps block occupancy or vacancy views (hub)
- Analytics module — Occupancy KPIs on mapped units after channel sync (hub)
- Listings module — Property wizard, Channels tab, Archived inventory, and unit management (hub)
- Properties workspace — Legacy
/propertiesURL redirects into Listings (hub) - Booking engine details — Rich marketplace payload editor via the Full integration pill (hub)
- Finance module — Portfolio ledgers with payment approval and deposit settlement (hub)
- Tenants module — Tenant directory and profile sidebars for imported stays (hub)
- Sales module — Portfolio availability, monthly rent editing, and channel manager connections (hub)
- Utilities module — Bills Included ceiling model and tenant overage charges on payment plans (hub)
- Operations module — Maintenance tickets, cash flows, and check-in/out coordination (hub)
- Inbox module — Portfolio-wide WhatsApp workspace (hub)
- Notifications module — Full
/notificationshistory with search and filters (hub); Payment overdue alerts when mapped partner imports leave unpaid schedules - AI Chat module — AI Assistant using Landlord MCP tools (hub)
- Account Settings — Workspace-wide financial policies, templates, integrations, and operational defaults (hub)