Skip to main content

Full listing feeds

First-time workspace setup

Full publish pulls (GET …/:landlordKey/listings/full) need rich catalogue data operators edit in Property & listing details (booking engine) — finish Getting Started — Recommended Setup Sequence steps 11–13 (Integrations, Integration field capability, Listings wizard + Full integration pill) before partners ingest. Resolve landlordKey and externalId per Property & Unit Mapping; pair ongoing sync with partial Listings & Availability and Onboarding a New Property — Step 7. Guide pairing after go-live: Setup sequence after go-live (hub: API Reference — Setup sequence after go-live).

Major marketplace integrations expose a second listing pull beyond the shared partial contract in Listings & Availability. Full feeds return publish-ready JSON shaped for each partner’s catalogue ingest — descriptions, amenities, photos, location blocks, and partner-specific sections — not just calendar, pricing, and availability windows.

Partial vs full
  • PartialGET /{platform}-integration/listings and GET /{platform}-integration/listings/:externalId — shared ListingDto (or platform extension) for sync and booking import. See Listings & Availability and API Reference — Partial vs full integration feeds.
  • FullGET /{platform}-integration/:landlordKey/listings/full (+ single-listing variants) — partner schema for listing create/update on the channel.
Swagger is authoritative

Field names, nested objects, and required blocks follow each integration’s OpenAPI models (for example UniplacesFullFeedListingDto, SpotahomeFullFeedListingDto). Open your provisioned prefix on the API host — see Try requests in Swagger.

landlordKey

Pair with other Full listing feeds sections

Resolve landlordKey against account integration email or stored key — see Property & Unit Mapping. Inbound webhooks require stored landlordKey only — Webhooks & Notifications — Uniplaces. Full endpoint map: Full listing feeds section cross-reference.

Full-feed paths include a landlordKey path segment. Vivin resolves it to the account whose listings you may export:

Value in the pathResolves to
The account’s stored landlordKeyThat Vivin account’s listings (whole-account feed)
The account’s integration email for that platformThe same account when the email matches the platform card under Account Settings → Integrations (accountIntegration.integrationEmail, compared case-insensitively)

Both forms scope the feed to the same account’s enabled listings. Use whichever identifier your onboarding contract names.

Webhooks use account landlordKey only

Inbound partner webhooks (POST …/{landlordKey}/webhook) still require the account’s stored landlordKey in the path — not the integration email. See Webhooks & Notifications — Uniplaces.

Single-listing full routes use the same resolution rules plus the listing’s externalId (the integration reference you mapped in Listings).

Platform matrix

Pair with other Full listing feeds sections

Inspect live schemas in Try requests in Swagger — models such as UniplacesFullFeedListingDto and HousingAnywhereFullFeedListingDto. Partial contrast: Listings & Availability. Full endpoint map: Full listing feeds section cross-reference.

PlatformRoute prefixFull bulk pathSingle full pathResponse wrapper
Uniplacesuniplaces-integrationGET /:landlordKey/listings/fullGET /:landlordKey/listings/:externalId/fullJSON array of Uniplaces-shaped listings (snake_case)
Spotahomespotahome-integrationGET /:landlordKey/listings/fullGET /:landlordKey/listings/:externalId/full{ "properties": [ … ] } matching Spotahome JSON Feed
Housing Anywherehousinganywhere-integrationGET /:landlordKey/listings/fullGET /:landlordKey/listings/:externalId/fullJSON array of HA-shaped listings
Inlifeinlife-integrationGET /:landlordKey/listings/fullGET /:landlordKey/listings/:externalId/fullJSON array of Inlife-shaped listings

All full routes use the same Bearer secret as the partial routes on that prefix (for example UNIPLACES_INTEGRATION_SECRET, SPOTAHOME_INTEGRATION_SECRET). Webhook endpoints, where provisioned, are documented in each integration’s Swagger group.

Overlapping unavailabilities in full feeds

When multiple manual blocks or calendar holds overlap or touch on the same unit, Vivin merges them into a single closed date range before exporting to full feeds — Uniplaces blocked_periods, Spotahome occupancies, Housing Anywhere blockedPeriods, and Inlife unavailability. This matches the coalescing already applied on partial GET /listings exports, so partners do not receive duplicate or fragmented blocks for the same unavailable window. Open-ended blocks (no end date) pass through without merging.

Placeholder image URLs (full feeds)

Partner channels fetch every image URL Vivin publishes. Known placeholder or stock-image hosts (for example picsum.photos, placehold.co, via.placeholder.com, dummyimage.com, loremflickr.com) are stripped from full-feed exports across Uniplaces, Spotahome, Housing Anywhere, and Inlife — even when those URLs remain on listing or property image rows inside Vivin. This keeps partners from rejecting or silently skipping listings when a placeholder URL is unreachable on their side. Replace placeholders with real photo URLs before expecting a catalogue row to pass partner image minimums.

Inlife — date fields as epoch milliseconds

On the Inlife full feed, every calendar date field is serialized as a numberUnix epoch milliseconds (JavaScript Date.getTime() / ES long), not an ISO-8601 string or YYYY-MM-DD text value.

Inlife’s landlord and room Elasticsearch mappings store these properties as long. Because the Vivin (ams) integration is marked same_structure: true on their side, Inlife indexes the payload as-is. A string date causes indexing failures such as failed to parse field [availableFrom] of type [long].

Field (room / listing object)Meaning
availableFromFirst day the room can be booked
firstAvailabilityFirst available day after active unavailabilities (when Vivin computes it)
creationDate / modificationDate / updatedListing lifecycle timestamps on the property or room block
unavailability[].from / unavailability[].toBlock window bounds on each unavailability row

Example fragment (values are illustrative):

{
"availableFrom": 1735689600000,
"firstAvailability": 1736294400000,
"updated": 1717242896000,
"unavailability": [{ "from": 1738368000000, "to": 1738972800000 }]
}

Convert in your consumer with new Date(value) when you need human-readable dates. Other Inlife full-feed scalars (rent amounts, booleans, photo URL strings) follow the OpenAPI models on the inlife-integration Swagger group — see InlifeFullFeedListingDto and nested DTOs.

Try requests in Swagger

Open your provisioned prefix on the API host, authorize with Bearer, and expand the listings (or partner-named) group — full routes appear alongside partial GET /listings where your contract includes them:

Integration Swagger UI — listings group with schema and Try it out

Step-by-step UI flow: API Reference — Try requests in Swagger. Operator-maintained fields that populate full-feed blocks are mapped in Integration field capabilities.

Housing Anywhere — partial feed uses costs

The Housing Anywhere partial pull does not return the generic ListingDto alone — each row is ListingHousingAnywhereDto, which extends the shared listing fields with a costs array (deposit, admin fee, utility lines, and so on). Amounts in the partial HA contract are in EUR (same as other partial feeds).

The full HA feed uses a separate schema (HousingAnywhereFullFeedListingDto) with amounts in cents and richer facility/image blocks. Do not assume partial and full rows are byte-identical — poll the feed your integration contract specifies.

Cost field (partial costs[])Typical meaning
typesecurity-deposit, administration-fee, cleaning-fee, utility bill types, etc.
valueAmount in EUR (nullable when not applicable)
payableAt / payableByWhen and who pays (move-in, monthly, tenant, landlord, included-in-rent, …)
refundable / estimated / mandatoryPartner semantics for display and validation

Spotahome — legacy feed vs partial vs full

Spotahome exposes three listing surfaces:

FeedPathUse
Legacy JSON feedGET /spotahome-integration/listings/feed or GET /spotahome-integration/listings/feed/:landlordKeyOlder SpotAHomeFeed shape ({ "properties": [ … ] }). Prefer full feed for new work unless your contract still references /listings/feed.
PartialGET /spotahome-integration/listings (+ /:externalId)Shared ListingDto calendar/pricing contract — same as Listings & Availability.
FullGET /spotahome-integration/:landlordKey/listings/full (+ single listing)Spotahome JSON Feed rules (location fields, image minimums when URLs exist, etc.). Compare with Spotahome’s public example.json in their partner docs.

Example requests

Pair with other Full listing feeds sections

Authorize with Authentication before your first full-feed GET. Spotahome legacy /listings/feed contrast: Spotahome — legacy feed vs partial vs full. Full endpoint map: Full listing feeds section cross-reference.

Replace {base}, {landlordKey}, and {externalId} with values from onboarding.

GET /uniplaces-integration/{landlordKey}/listings/full HTTP/1.1
Host: api.vivin.app
Authorization: Bearer YOUR_API_KEY
GET /housinganywhere-integration/{landlordKey}/listings/{externalId}/full HTTP/1.1
Host: api.vivin.app
Authorization: Bearer YOUR_API_KEY
GET /spotahome-integration/listings/feed/{landlordKey} HTTP/1.1
Host: api.vivin.app
Authorization: Bearer YOUR_API_KEY
GET /inlife-integration/{landlordKey}/listings/full HTTP/1.1
Host: api.vivin.app
Authorization: Bearer YOUR_API_KEY

Choosing partial vs full

Pair with other Full listing feeds sections

Calendar-only subscribers should read iCal feeds instead of JSON pulls. Booking import always uses POST /bookingsCreating Bookings. Full endpoint map: Full listing feeds section cross-reference.

Your integration needs…Poll
Calendar, pricing, availability windows, booking importPartialListings & Availability
Rich catalogue publish (photos, amenities, partner blocks)Full — this page
Short-term calendar blocks onlyiCaliCal feeds (not JSON)

Many partners poll both: full feed on a slower cadence for listing create/update, partial feed every 15–30 minutes for availability and rates.

Operator field mapping

Full feeds serialize from the same Listings / Full integration pill content operators maintain in the management app. Which Vivin fields populate each partner block — and which are required before publish — is summarised in Integration field capabilities and Property & listing details (booking engine).

Sync strategy

Pair with other Full listing feeds sections

Partial poll cadence and updatedAt diffing: Listings & Availability — Sync Strategy. Push updates: Webhooks & Notifications (listing.updated). Full endpoint map: Full listing feeds section cross-reference.

Feed typeTypical poll intervalChange detection
Full catalogueEvery few hours to daily (per partner SLA)Re-pull entire array or diff by partner listing id + updatedAt when the schema exposes it
Partial calendarEvery 15–30 minutesupdatedAt on ListingDto rows — see Listings & Availability — Sync Strategy

Import bookings through POST /{platform}-integration/bookings regardless of which listing feed you poll — see Creating Bookings.

Full listing feeds section cross-reference

Use this table when one full-feed topic naturally leads into another API guide, operator UI, or downstream workflow — each row links to the docs you should read before or after wiring publish pulls.

API topic / sectionPair with these docs
landlordKeyProperty & Unit Mapping, Webhooks & Notifications — Uniplaces (inbound path segment)
Platform matrixTry requests in Swagger, Listings & Availability (partial contrast)
Example requestsAuthentication, Error Handling (404 on unknown externalId)
Choosing partial vs fulliCal feeds, Creating Bookings, Notifications — Payment overdue alertsHandling a Late Payment — Step 1 (full-feed partner imports), Glossary — Credit note (payment reject/revert), Glossary — Invoiced floor (rent)
Sync strategyWebhooks & Notifications, Listings & Availability — Sync Strategy

| Lockout catch-up after password recovery | Publish backlog after sign-in recovery | Common Workflows — Lockout catch-up, Webhooks & Notifications, Listings — Channels tab | | Pending manual receipt approval | Catalogue imports with pending receipts | Common Workflows — Pending manual receipt approval, Creating Bookings, Finance — Pending manual payments | | Reject/revert mistaken receipts | Duplicate publish imports | Common Workflows — Reject/revert mistaken receipts, Cancelling a Booking, Payment Allocation — Correcting mistaken receipts | | Portfolio segmentation by tenant category | Segment triage on full-feed imports | Common Workflows — Portfolio segmentation, Settings > Tenant categories, Bookings — Other filters | | Notification row-click navigation | Catalog sync vs operator alert triage | API Reference — Notification row-click navigation, Common Workflows — Notification row-click navigation, Notifications module — Notification row-click navigation | | Payment alert to receivables triage | Feed traffic vs payment overdue | API Reference — Payment alert to receivables triage, Common Workflows — Payment alert to receivables triage, Handling a Late Payment — Step 1 | | Confirmation alert triage | New inventory vs confirmation alerts | API Reference — Confirmation alert triage, Common Workflows — Confirmation alert triage, Processing a New Booking — Step 5b | | Finance debt receivables triage | Portfolio rank after feed-driven imports | API Reference — Finance debt receivables triage, Common Workflows — Finance debt receivables triage, Finance module — Finance debt receivables triage | | Handling a Late Payment collections | Integration surface vs operator collections Steps 1–6 | | Finance Income status drill-down | Rent caps vs Income segments | API Reference — Finance Income status drill-down, Common Workflows — Finance Income status drill-down, FAQ — Finance Income status drill-down hub | | Cash flow forecast drill-down | Feed pricing vs collections bars | API Reference — Cash flow forecast drill-down, Common Workflows — Cash flow forecast drill-down, FAQ — Cash flow forecast drill-down hub |


Pair with other Full listing feeds guide sections

Related below links catalogue publish payloads to setup, companion API guides, operator workflows, and escalation paths. Pair Setup sequence after go-live with Getting Started — Recommended Setup Sequence; pair Companion API guides with API Reference hub. Topic-to-guide pairing in sections above: Full listing feeds section cross-reference. Full hub matrix: API guide cross-reference.

Setup sequence after go-live

Pair with other Full listing feeds guide sections

Documentation map & escalation

Pair with other Full listing feeds guide sections

Companion API guides

Pair with other Full listing feeds guide sections

Companion guides share Bearer authorization or error shapes with this page — start from API Reference hub. Full pairing matrix: Full listing feeds section cross-reference.

Upstream & downstream workflows

Pair with other Full listing feeds guide sections

Workflow bullets pair with Common Workflows — Workflow cross-reference after partner traffic lands in the management app. Full pairing matrix: Full listing feeds section cross-reference.

Operator UI & settings

Pair with other Full listing feeds guide sections

Operator UI rows validate the same inventory and permissions behind integration HTTP — pair with Account Settings — Tab cross-reference. Full pairing matrix: Full listing feeds section cross-reference.

Deeper concept reads

Pair with other Full listing feeds guide sections

Deeper workflow reads

Pair with other Full listing feeds guide sections

Workflow reads pair with Common Workflows hub subsection index and Workflow cross-reference. Each workflow sub-guide also has its own Deeper API reads subsection with reciprocal companion API anchors — hub parity: API Reference — Deeper workflow reads. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Lockout catch-up after password recovery

Pair with other Full listing feeds guide sections

Full-feed catalogue polls may continue during operator lockout — reconcile Channels tab and webhook backlog after sign-in recovery. Hub parity: Common Workflows — Lockout catch-up after password recovery. Full pairing matrix: full-listing-feeds-section-cross-reference · API guide cross-reference.

Pending manual receipt approval

Pair with other Full listing feeds guide sections

Publish feeds do not encode receipt state — pair with Creating Bookings enqueue and Finance pending approval on imported stays. Hub parity: Common Workflows — Pending manual receipt approval. Full pairing matrix: full-listing-feeds-section-cross-reference · API guide cross-reference.

Reject/revert mistaken receipts

Pair with other Full listing feeds guide sections

Duplicate catalogue bookings from re-publish cycles pair with Cancelling a Booking and receipt Reject / Revert. Hub parity: Common Workflows — Reject/revert mistaken receipts. Full pairing matrix: full-listing-feeds-section-cross-reference · API guide cross-reference.

Portfolio segmentation by tenant category

Pair with other Full listing feeds guide sections

Full-feed landlordKey scoping is account-wide — segment imported tenants via Settings > Tenant categories. Hub parity: Common Workflows — Portfolio segmentation by tenant category. Full pairing matrix: full-listing-feeds-section-cross-reference · API guide cross-reference.

Notification row-click navigation

Pair with other Full listing feeds guide sections

Full-feed catalogue pulls do not clear /notifications — operators row-click booking-import alerts after feed-driven reservations land. Hub parity: API Reference — Notification row-click navigation. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Payment alert to receivables triage

Pair with other Full listing feeds guide sections

Rich feed imports that create unpaid schedules surface payment overdue rows — row-click before Debt Aging collections. Hub parity: API Reference — Payment alert to receivables triage. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Confirmation alert triage

Pair with other Full listing feeds guide sections

New full-feed inventory often triggers Upcoming Booking created alerts — pair feed go-live with Onboarding — Step 7. Hub parity: API Reference — Confirmation alert triage. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Finance debt receivables triage

Pair with other Full listing feeds guide sections

High-volume full-feed partners inflate receivables — triage Top debtors after alert row-click on imported stays. Hub parity: API Reference — Finance debt receivables triage. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Handling a Late Payment collections

Pair with other API Reference hub sections

Partner integration reads on Full Listing Feeds do not replace operator collections — payment overdue in-app rows still need Handling a Late Payment — Steps 1–6 after receivables triage. Hub parity: Common Workflows — Handling a Late Payment collections hub. Full pairing matrix: full-listing-feeds-section-cross-reference · API guide cross-reference.

Finance Income status drill-down

Pair with other Full listing feeds guide sections

Dual-pricing feed fields may skew Income → Scheduled — segment-click reconcile on Finance → Overview after first feed bookings. Hub parity: API Reference — Finance Income status drill-down. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Cash flow forecast drill-down

Pair with other Full listing feeds guide sections

Feed-driven booking payments settle on Cash flow forecast bars separately from catalogue GET traffic timing. Hub parity: API Reference — Cash flow forecast drill-down. Full pairing matrix: Full listing feeds section cross-reference · API guide cross-reference.

Key glossary terms

Pair with other Full listing feeds guide sections

Glossary rows pair with Glossary cluster cross-reference and receipt-dispute workflows. Full pairing matrix: Full listing feeds section cross-reference.

Module documentation hubs

Pair with other Full listing feeds guide sections

Module hubs pair with Modules — Module cross-reference for screen-by-screen operator follow-up. Full pairing matrix: Full listing feeds section cross-reference.

  • Listings module — Inventory source for publish payloads partners ingest (hub)
  • Audit module — Manual blocks on published units that still appear in partner availability pulls (hub)
  • Dashboard module — Post-login KPI snapshot with bell notification triage (hub)
  • Analytics module — Month-range portfolio KPI charts with rankings and heatmaps (hub)
  • Properties workspace — Legacy /properties URL 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 when actual costs exceed billsIncludedMaxValue (hub)
  • Operations module — Maintenance tickets, cash flows, and check-in/out coordination (hub)
  • Inbox module — Portfolio-wide WhatsApp workspace (hub)
  • Notifications module — Full /notifications history with search and filters (hub); Payment overdue alerts when full-feed partner imports leave unpaid schedules
  • AI Chat module — Vivin-internal AI Assistant using Landlord MCP tools (hub)
  • Account Settings — Workspace-wide financial policies, templates, integrations, and operational defaults (hub)