Publishing properties

Publishing is a backend operation. The CRM keeps original images; websites, the external catalogue, the public portal and PDF exports use separate watermarked copies.

Existing photos grandfathered during migration retain unmarked copies with independent public URLs. New uploads still receive watermarks, including new photos added to an existing property. This exception cannot be requested through the API.

Integration flow

1. Create a contact if the property needs a holder. Contacts are private CRM records, not public listings.
2. Create a property with its operation, price, location privacy, area and characteristics. Save the returned ID.
3. Prepare uploads, PUT each accepted photo to its temporary upload URL, and complete the session.
4. Request publication with published: true.
5. Poll status until published: true, or handle a failed job. Then retrieve the listing.

Give an importer properties:write, properties:publish and optionally leads:write. A public website needs only properties:read and, for contact forms, leads:ingest.

Photo protection

The workspace's logo is centered and translucent. If no customer logo exists, a small Vestta SVG mark appears at the bottom right. URLs and image IDs are random and independent from the original. Public responses contain neither private paths nor original filenames.

If processing fails, no original photo is substituted. Downloads from the authenticated CRM remain unmarked. Preparing a PDF's marked photos does not publish the property.

Migration from the old API

The only API base is now https://api.vestta.app/v1; the former mount has been removed. Update your integration's base URL before switching traffic. Existing API keys keep their scopes: write and publish permissions must be explicitly granted on a new key.

Errors now use application/problem+json, valid keys without permission receive 403, and count is the total on both list resources. Response envelopes stay status plus data for reads; creates and updates return status plus id.