| Method | Pros | Considerations | Who usually owns it |
|---|---|---|---|
| SFTP file drops | Familiar, simple to operate for marketers with IT help. Leverages existing Core reports. | Not real time. Requires scheduled exports and monitoring. | IT builds exports, Marketing reviews and uses data. |
| API-based sync | Near real time updates. Reduces file handling. | Requires developers or a middleware partner to build and maintain. | IT or a partner implements, Marketing benefits from fresher data. |
Many credit unions use their Core’s report tooling to create daily extracts that land on Delivra’s SFTP, then map into custom tables for segmentation and automation. Some examples are:
Nightly exports from Keystone via internal SQL-like scripts, loading multiple files into Delivra custom tables which is used to trigger automated messaging.
Hourly automated data syncs for more timely messaging needs, such as account opens and closes, welcome emails, and branch outreach.
Decide what messages you want to send and what data is needed to support them, for example new account welcome, cross-sell by product, branch-based outreach.
Decide on how often Delivra should receive updated information. This is usually nightly for larger files like member and product updates and hourly for more individualized messages.
Ask IT to follow the developer notes below.
After the first load, build segments and automations that reference your custom tables.
Most teams use their Core’s scripting layer to generate CSVs that land on Delivra’s SFTP. In many environments this scripting is SQL-esque and scheduled, for example PowerOn-style exports that run nightly and push via a secure client such as MoveIt.
Include a durable primary key such as Member_ID for every file.
Prefer ISO-8601 dates like 2025-11-06.
Choose full or delta loads. If sending deltas, include Change_Type and Change_Timestamp for easy troubleshooting.
Use consistent field names across files to simplify mapping.
Keep PII to what marketing truly needs.
Establish predictable file naming and one file per entity per run, for example members_YYYYMMDD.csv.
Below are simple examples you can adapt. Add fields as needed.
All Members file
Example headers:Member_ID,Email,FirstName,LastName,Status,Branch_ID,OptIn_Email,Open_Date,Last_Updated
Products or Shares file
Example headers:Member_ID,Product_Code,Product_Name,Open_Date,Status,Balance,Last_Updated
Member Change file (delta)
Example headers:Member_ID,Change_Type,Field_Changed,Old_Value,New_Value,Change_Timestamp
Branch file
Example headers:Branch_ID,Branch_Name,City,State,Zip,Phone
Run exports nightly or as often as your marketing needs.
Deliver CSVs to Delivra via secure SFTP. Any standard SFTP client will work that can deliver files to a remote SFTP site.
Create or request custom tables that mirror your files, for example Members, Products, Branches.
Map required keys, for example Members.Member_ID as the parent key and Products.Member_ID as the foreign key.
Align data types to avoid truncation, for example numeric for balances, date for open dates.
Validate with a small test batch, then promote the schedule.
To prevent messaging lags or stale contacts, consider a nightly rule that marks contacts expired if they do not appear in the Members file, then reactivate them when they reappear in the next file. This addresses the common scenario where accounts close in Core but contacts remain active in marketing.
Use the Member Change file to trigger targeted updates instead of resending full files during the day.
Define the minimal data needed for automations and personalization.
Coordinate with IT or a partner on event timing, for example member created, product opened, account closed.
Build a small service that listens to Core events or database changes, then calls Delivra’s API to insert or update contacts and related tables.
Use middleware or an integration platform as a service to translate Core events into Delivra API calls.
For supported tasks, Zapier can be used. There are no Delivra fees for Zapier connections, though Zapier may charge.
Use a stable external ID for contacts, for example Member_ID.
Send subscription status and email permission flags with each update.
For product ownership, maintain a related table keyed by Member_ID plus Product_Code.
Emit lifecycle events that matter for marketing, like New Member, Product Opened, Product Closed.
Start simple. Ship one dependable Members file first, then add Products and Branches.
Name files consistently so monitoring is straightforward, for example members_20240612.csv.
Validate early with a limited audience before going live.
Document every field and its source in a short data dictionary for marketers and IT to share.
Keep an eye on compliance and opt-in fields, especially for promotional messaging.
New Member Journeys: Trigger welcome series from the Members file or API event when Open_Date is present.
Cross-sell by Product: Use the Products or Shares table to promote relevant add-ons.
Branch-localized Messaging: Use Branch_ID to personalize store hours, addresses, or teams.
Account Closure Suppression: Apply the nightly expire-and-reactivate pattern so closed accounts stop receiving product communications.
Whether your Core is Keystone, EASE, or another variant, you can start quickly with SFTP exports and grow into API-based syncing as your needs evolve. Begin with a lean file, keep keys consistent, and your data will fly in formation across marketing and Core.