Skip to main content

Luminate Online – Connector Documentation

Written by Philippe Trussart

Last updated on 9/18/2025

Overview

This connector syncs key Luminate Online objects into your data lake. For each table, the connector stores:

  • The object’s native JSON payload (under a column named after the Luminate object type, e.g., Constituent, Donation, EmailMessage).

  • One or more identifier columns (when available).

  • dmi_last_updated_at (ISO 8601 timestamp of when the record was written).

Authentication & Setup

Provide the Luminate Online endpoint and credentials:

  • Endpoint (base URL)

  • Partition ID

  • Username

  • Password

Sync Strategy

  • Incremental (modify indicator): Most tables filter by the object’s modify/updated field (noted per table below).

  • Luminate Synchronization API: Some high-volume objects (e.g., donations, email objects) use Luminate’s synchronization workflow for inserts/updates/deletes.

  • Full replace: Tables without a modify indicator are fully refreshed (truncate + reload) on each run.

  • Activity Streams lookback: Capped at 180 days per run. The connector overrides the starting checkpoint to “now − 180 days” when syncing this table.

  • Deletes: Soft-delete events are emitted only for donations (keyed by TransactionId).

  • Paging: Requests use a page size of 200.

  • Retries: Automatic retries with ~65s intervals up to ~40 minutes total.

Primary Keys & Uniqueness

  • When an ID (or set of IDs) exists for an object, those fields serve as the record’s key.

  • Objects without a stable ID (e.g., crossreferencevalues, organizationcontacts) do not have a natural key; downstream consumers may derive a surrogate key if needed.

  • The JSON payload column (e.g., Constituent, Donation) is a full snapshot of the object returned by the API for that sync run.

Deletes

  • Donations: soft-delete events are captured (key: TransactionId).

  • Other tables currently do not emit delete events, even when using the synchronization API.

Known Limitations & Notes

  • Activity Streams are limited to a 180-day sliding window per sync run (to keep runs performant). Older data will not be queried during a given run.

  • Some metadata fields are intentionally filtered from queries (e.g., internal pre-deduplication fields).

  • Large email recipient populations can make those syncs slower; the synchronization workflow is used to keep them reliable.

  • A few reference/helper lists are full-refresh only: crossreferencevalues, crossreferencetypes, grouptypes, interests, surveyanswers, surveyquestions, organizationcontacts.

Did this answer your question?