Automations

PropSocket runs scheduled jobs for you. Define an automation once — a cron expression, a timezone, and what it should do — and the platform executes it on schedule, retries transient failures, and records what happened on every run. No worker to deploy, no scheduler to babysit, no scratch storage to provision.

Today, automations do one thing: export your normalized data to CSV and push it to your own SFTP or FTP server. The model underneath is generic on purpose — the automation type is a discriminator, and CSV export is the first type. The model was built to hold more.

Every automation has a cron schedule, an IANA timezone (default America/New_York), a status you can pause and resume, and a run history. This page covers what you can export, where it lands, how files are named, what happens when a run fails, and how to get notified.

How an automation runs

You configure automations in the dashboard — there's no separate API to wire up. Each one holds four things: an export config (what data), a destination (where it goes), a filename template, and a schedule. On every tick of the cron, PropSocket builds the file, pushes it, and writes a run record. You can alsorun an automation on demand from the dashboard, andtest the destination connection before you save it.

CSV exports: what you can export

A CSV export automation targets one entity per automation. Pick from the five CDM entities:

• property
• unit
• resident
• lease
• lease_resident

Columns

Each entity has a fixed column catalog. You select a subset, in the order you want them — that becomes your header row and column order. The catalog is closed: you choose among the documented fields, not arbitrary or computed columns. As an example, theunit catalog:

The other four entities have their own catalogs in the same shape. Money fields are integer minor units (cents) with a separate currency column; nested fields like emails and phones serialize as JSON in a single cell.

Filters

Narrow the rows with the same filters the REST API uses. If you can express it as a query against GET /v1/units, you can express it as an export filter — same fields, same semantics. See Filtering & sorting for the full filter set per entity.

Integration scope

By default an export spans every integration in your organization. Scope it to a single integration when you want one feed per source — for example, a separate file per property-management system you've connected.

Delivery: your SFTP or FTP server

PropSocket pushes the finished file to a server you own. There is no PropSocket-hosted file, no download link, no shared bucket — delivery is push-only, to your destination. The dashboard shows run history (count, file size, status), never the file itself.

Credentials — passwords and private keys alike — are encrypted at rest. UseTest connection in the dashboard to confirm the destination works before you save. Because the file lands on your server, retention, downstream pickup, and archival are yours to define; PropSocket's responsibility ends when the push succeeds.

Filenames

The remote filename is a template you control. The default is {model}_{date}.csv. Available tokens:

# Default
{model}_{date}.csv          ->  unit_2026-06-08.csv

# One file per run, never overwritten
{model}_{timestamp}.csv     ->  unit_20260608T060014.csv

# Foldered per source
{integration}/{model}.csv   ->  entrata-prod/unit.csv

Pick a template that keeps each run distinct if your consumer doesn't want files overwritten —{model}_{timestamp}.csv never collides; {model}_{date}.csvproduces one file per day.

Scheduling & reliability

The schedule is a standard cron expression plus an IANA timezone (defaultAmerica/New_York). The timezone is honored across DST transitions, so a job pinned to06:00 local stays at 06:00 local.

# Cron + IANA timezone, configured in the dashboard.
# "At 06:00 every day, America/New_York" — honored across DST.
0 6 * * *        America/New_York

• Run cap. Each run has a 30-minute ceiling. A run that exceeds it is stopped and recorded as failed. If an export is brushing the cap, tighten the filters or split the work across narrower automations.
• Transient failures retry. Connection resets, timeouts, and a server briefly refusing connections retry with backoff — 1 minute, then 5, then 15. Exhaust those and the run is dead-lettered for inspection.
• Permanent failures don't retry. Bad credentials, permission denied on the remote path, and similar unrecoverable errors fail the run immediately, with no retries — retrying wouldn't help, and the run record names exactly what to fix.
• Run history. Every run records its status, the number of rows exported, the file size, and timing — your audit trail of what was delivered, when, and how much.
• Pause and resume. Pausing stops an automation from running without deleting its configuration or history. Resume it and the next scheduled run fires normally — handy while you rotate SFTP credentials or drain a downstream backlog.

Notifications

Every run emits a webhook, so you don't have to poll the run history. Webhook delivery is on theScale plan and above (Scale and Enterprise); on Growth, check the run history in the dashboard instead — see pricing.

• AUTOMATION_COMPLETED — the run finished and the file was delivered.
• AUTOMATION_FAILED — the run failed, whether immediately (permanent error) or after exhausting retries (transient error). The payload carries the error_message andattempt_number.

Subscribe to these the same way you subscribe to any other event — the envelope, signing, retries, and idempotency are identical. See Webhooks for verification and delivery semantics, including how to dedupe on the event id.

{
  "id": "evt_01HXA5Q9R7N2KJ4BWZ8M3VYC6D",
  "type": "AUTOMATION_COMPLETED",
  "category": "automation",
  "created_at": "2026-06-08T06:00:14Z",
  "organization_id": "b3f1c2d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
  "integration_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "data": {
    "automation_id": "atm_01HXA4T0V8P5LFXCZW3RNS5EDG",
    "automation_name": "Nightly units -> BI SFTP",
    "run_id": "aru_01HXA5Q8N4M2KJ4BWZ8M3VYC6D",
    "records_exported": 2483,
    "file_name": "unit_2026-06-08.csv"
  }
}

{
  "id": "evt_01HXA5R0S8P3LK5CXA9N4WZD7E",
  "type": "AUTOMATION_FAILED",
  "category": "automation",
  "created_at": "2026-06-08T06:45:31Z",
  "organization_id": "b3f1c2d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
  "integration_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "data": {
    "automation_id": "atm_01HXA4T0V8P5LFXCZW3RNS5EDG",
    "automation_name": "Nightly units -> BI SFTP",
    "run_id": "aru_01HXA5R0N4M2KJ5CXA9N4WZD7E",
    "records_exported": 0,
    "file_name": "",
    "error_message": "SFTP authentication failed",
    "attempt_number": 1
  }
}

A common pattern: route AUTOMATION_FAILED to your on-call channel, and treatAUTOMATION_COMPLETED as the signal to kick off downstream processing of the file you just received.

When to self-host instead

Managed automations are the right call when you want PropSocket to own the schedule and the transport. Sometimes you'd rather own them yourself — you already run a scheduler, you need a destination automations don't deliver to, or you want full control over the file shape and the transfer.

For that, pull the REST API on your own schedule.Export units for one property nightly to CSV walks through a paginate-and-write loop you can run from cron, a Celery beat task, or a GitHub Action, and deliver however you like. Same normalized data, your schedule and transport.

Next

Wire run notifications into your pipeline with Webhooks, or narrow what an export contains with Filtering & sorting.