Yardi Voyager integration

Last updated date:

How Seedling connects to Yardi Voyager, which read-only information it uses, and how access and deletion are controlled.

1. Overview

The implemented Yardi connector registers a customer-controlled artifact directory or extractor request/result file drop. It does not ask for a Yardi API key or OAuth secret in the current manual extraction path.

Seedling reads only approved Voyager backup or SQL-export artifacts, binds them to the exact workspace account, and keeps property and financial projections closed until declared access is assigned.

2. Connection and scope

Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.

Approved extraction artifacts
Provide the stable Yardi account ID and either an artifact directory or both extractor request and result directories. An optional backup path identifies the approved source artifact.
Connection ownership
This connector is workspace-only. A current Seedling workspace administrator controls installation, credential replacement, disconnect, and purge for the exact connection.

3. Yardi Voyager data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Extraction artifacts
Authorized files produced through the configured Yardi Voyager export, Data Connect, Replicate, backup, or file-drop process.
Property operations
Properties, units, tenant leases, tenant charges, vendors, and configured operational relationships.
Financial context
General-ledger accounts and transactions, income statements, balance sheets, books, and property relationships present in approved artifacts.

4. Read-only permission contract

The Yardi-side extractor or export process must be read-only and limited to approved artifacts.

  • YARDI_BACKUP:Read — read explicitly approved Voyager backup artifacts.
  • YARDI_SQL_EXPORTS:Read — read explicitly approved SQL export/file-drop artifacts.
  • Provide either one artifact directory or both extractor request and result directories; Seedling does not scan arbitrary filesystem paths.
  • No Yardi API key, OAuth secret, database write, export mutation, or provider-record mutation is requested by this setup.

5. Security and access

  • Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
  • Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
  • Workspace objects begin with no human audience. A current workspace owner or source steward must assign the provider-defined scopes for this exact connection to active members; membership, administrator or steward status, installer identity, and provider roles grant no raw-content bypass.
  • Declared human access can be assigned by data type and, when present in provider metadata, exact property. Properties, units, leases, tenant charges, vendors, general-ledger records, statements, and books receive no human audience until assigned.
  • Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data
Synchronized Yardi Voyager records remain while the connection is active and are removed through a durable integration purge after disconnect.
Credentials
Stored Yardi Voyager credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
Backups
Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.