/
Calyx Integration Exploration

Calyx Integration Exploration

Ticket: V2DEV-29155 — "Calyx Integration - Exploration" (Spike). Ask: explore the Calyx integration and understand what's needed to integrate with Experience.com for customer business use cases.

Related ticket: V2DEV-29035 — "Calyx Integration & Application - Details _Feasibility check" (linked as "relates to" V2DEV-29155, status Dev Completed). Its comment thread is the source for Sections 1–2 below.

Purpose: This document consolidates two things that must not be conflated:

  1. What Experience.com actually built and runs today for Calyx Point/PointCentral (Sections 1–2) — sourced from the internal Confluence pages linked to V2DEV-29035.

  2. The broader Calyx integration landscape — SDK, direct SQL, vendor marketplace, Path, and the Calyx Industry Connect partner program (Sections 3–6) — general Calyx documentation, useful for feasibility comparison but not what our production integration uses.

Section 7 answers V2DEV-29155's acceptance criterion — integrating with Experience.com for customer business use cases — directly.

1. The Two "Calyx" Products in Play

 

Calyx Point / PointCentral

Calyx Path

 

Calyx Point / PointCentral

Calyx Path

What it is

LOS with a SQL-backed "Point Data Server" (PDS); PointCentral is Point with a centralized, multi-user database

A separate, cloud-native LOS (browser-based, Calyx-hosted)

Status with Experience.com

Built and in production — documented setup/config guides dating back to 2020–2021, with the "Point Central" doc updated as recently as May 2025

Never built — a single 2020 "Requirement Analysis" page with open To-Dos ("check how to create a test account," "get the APIs to work") and no evidence of further work

Integration method

A Windows agent reads the client's Calyx SQL database directly, exports CSV, SFTPs it to Experience.com

Would have used Salesforce, an SDK, or an API (via Optimal Blue) through Calyx Path's "Lender Web Integration," which also needed an onboarding tie-in with Stewart (a title guaranty company)

The rest of this document's production-accurate content (Sections 1–2) covers Calyx Point/PointCentral only, since that's the one that's actually integrated. Calyx Path is covered separately in Section 3 as an unbuilt, exploratory item.

2. What's Actually Built: The Calyx Point / PointCentral Integration (Production)

Calyx Point is loan origination software used by lenders. It stores loan/transaction data (including loan officer and closing info) in a SQL database on the client's infrastructure. Experience.com does not have API access into Calyx Point. Instead, data is pulled out via a small Windows program pair called the Point Data Server (PDS) interface — originally branded "SocialSurvey PDS," now "Experience.com PDS."

There is no Calyx integration code in this repo; the integration runs on infrastructure outside the codebase (a Windows agent installed on or near the client's Calyx SQL server).

Components

  1. SS-PDS-Setup.exe — configuration GUI, run once per client install. It:

    • Takes SQL connection details for both the client's PDS/Calyx database and the Experience.com tracking database (created by this tool, not pre-existing).

    • Takes extraction settings (see below).

    • On save, tests the SQL connection and — on first run — creates an Experience.com/SocialSurvey database alongside the PDS database, with 4 tracking tables (SS_Processed, SS_LoanOfficer, SS_LoanOfficerName, SS_DebugMessage) used to dedupe already-sent records per loan officer.

    • Writes an encrypted Settings.cfg that SSPDSProcess.exe reads.

  2. SSPDSProcess.exe — the actual extraction job. Runs daily via Windows Task Scheduler and:

    • Queries the Calyx/PDS SQL database for transactions matching the configured Trigger Date (e.g., "Closed") within the Start Date → (today − Offset Date) window.

    • Cross-checks the tracking database to skip already-processed records per loan officer (dedup).

    • Exports results to CSV.

    • Uploads (SFTP) the CSV to Experience.com's SFTP server.

  3. Experience.com/SocialSurvey tracking database — MSSQL, created by the setup tool. Purely bookkeeping — which files/loan officers have already been sent, to avoid duplicate sends.

This is, in effect, the same read-only, direct-SQL pattern described generically in Section 4.2 below — except it's a purpose-built, pre-existing executable (PDS) rather than a custom script, and it delivers data via CSV/SFTP rather than pushing directly to an API.

Key extraction settings (configured per client)

  • Default Email — fallback email if the record's email is missing.

  • L.O. Email — which loan officer email field to use. Per the source docs, more likely sourced from the User file than the Loan Document file — flagged as needing per-client verification (open question, never closed out).

  • Start Date — earliest transaction date to pull.

  • Trigger Date — the date field that flags a transaction as ready to send (e.g., Closed/Funded/Recorded). "Closed" is the recommended trigger; "Recorded" reportedly failed for at least one past client.

  • Offset Date — trailing buffer; extraction runs Start Date through (current date − offset days), so very recent transactions aren't pulled prematurely.

  • Include Realtors — whether to include buyer/seller agents, not just the loan officer.

  • Include No Access — (Focus IT variant only) additional inclusion flag.

Hosting models (why there are 3 separate config guides)

Where the PDS agent runs depends on who hosts the client's Calyx SQL server:

  • Focus IT–hosted clients — Experience.com manages the install remotely.

    • Connects via RDP to a shared jump box: socialsurvey01.focuspds.net.

    • A per-client folder SS-<CLIENTCODE> (e.g., SS-SMILE001) is seeded from a SocialSurveyMaster template.

    • PDS-side SQL Server/Database/User/Password come from Focus IT; the Experience.com-side SQL Server is SOCIALSURVEY01, database SS_<CLIENTCODE>, credentials from SAM.

    • SFTP target is hardcoded to a specific IP with per-client SFTP credentials ("SS Use SFTP" must be checked).

    • Ends with a daily Windows Task Scheduler job pointed at SSPDSProcess.exe.

  • Self-hosted / customer-hosted / other-vendor-hosted clients — the client's own IT installs and configures it, following a customer-facing guide.

    • Package downloaded from an external URL (wittsoft.com, per the older doc) and unzipped on the client's own PDS server.

    • As of "Version 2" of the package, the PDS SQL server and the Experience.com SQL server no longer need to be the same physical machine — but the install machine needs network access to both.

    • Same flow: SS-PDS-Setup.exe → verify connection → Settings.cfg created → schedule SSPDSProcess.exe daily.

    • Sysadmin-level SQL privileges are required on the Experience.com-side database (it creates tables); the PDS-side connection can be read-only.

Setup + test is estimated at 1–2 hours per client, once credentials are in hand.

Open gaps (never explicitly closed out in the source docs)

  • Whether L.O. Email should come from the User file vs. the Loan Document file.

  • Whether the setup/process .exe files can be renamed per client for clarity in Task Scheduler.

  • How to handle clients whose network/firewall restricts direct PDS access.

  • Several source pages are from 2020–2021 and use "SocialSurvey" branding predating the "Experience.com" rename; the 2025-updated "Calyx Point Central" page reflects newer branding but describes the same mechanism.

3. Calyx Path — Status: Not Built

Calyx Path is a distinct, apparently abandoned integration attempt — nothing in Section 2 applies to it. Only a single 2020 "Requirement Analysis" Confluence page covers it, with To-Dos still open as of that page: create a test account, get the APIs to work, transaction creation. There is no evidence further work happened.

If V2DEV-29035 or a future ticket needs the Path (not Point) integration, essentially all groundwork — test account, API access, transaction creation — would need to start from scratch. See Sections 5–6 for what a Path integration would realistically require (partner-program route, not a self-service API).

4. Broader Point / PointCentral Integration Landscape (Feasibility Context Only)

The routes below come from Calyx's general product/developer documentation, not from Experience.com's own build. They're included here for feasibility comparison against the PDS approach in Section 2 — e.g., if we ever wanted to move off CSV/SFTP and onto a live query or write-back path.

Calyx does not offer a public, self-service REST API for Point or PointCentral. There are three practical routes in, ranked by how "supported" they are:

4.1 Point SDK (Official, Supported — Not Used in Our Production Integration)

  • A compiled .NET Framework 4.8 assembly (DLL), not a web-facing REST API.

  • Supports reading and updating loan file data from local Point installations or centralized PointCentral database environments, plus automated report generation from standard Point templates.

  • Requires a Windows environment and a language that can call into the .NET CLR.

  • Python access is possible via pythonnet, which loads the .NET assembly directly into a Python process:

import clr clr.AddReference("Calyx.Point.Sdk") import Calyx.Point.Sdk as PointSdk session = PointSdk.PointSession() is_connected = session.LoginToPointCentral(server_url, username, password)

Requirements: Windows + Point SDK/Point Client installed; outbound SSL (port 443) to tmsservice.calyxsoftware.com for runtime activation; pip install pythonnet.

This would be the route to consider only if a future need requires writing back into Point/PointCentral (e.g., updating loan file status) — our current PDS-based integration is read-only and does not use this SDK.

4.2 Direct SQL Server Access (Unofficial, Read-Only)

PointCentral's backend is a SQL Server database. For read-only extraction — pipeline metrics, borrower surveys, dashboards — it's possible to bypass the SDK and query the database directly (e.g., via pyodbc in a custom script). This is functionally what our PDS agent already does (Section 2), just packaged as a pre-built executable rather than custom code.

Critical constraint: this route is read-only in practice. Writing directly to tables bypasses PointCentral's compliance logic, database triggers, and file-locking — risking permanent data corruption. Any workflow that needs to change loan data belongs in the SDK path (4.1) instead.

Typical read targets: LoanMaster, Tracking, BorrowerInfo-style tables, with fields like borrower name/email, loan status codes (Closed, Funded, Approved), lender/originator ID, and milestone dates (e.g., ClosedDate) used as filters — consistent with the Trigger Date/Offset Date pattern our PDS setup already uses.

4.3 Vendor/Partner Integrations (Pre-Built, No Development Required)

Calyx maintains a directory of 100+ pre-integrated third-party vendors: credit reporting (Xactus, LexisNexis, Equifax, CoreLogic Credco), title/escrow (First American, Stewart Title, Fidelity National Title), flood certification (CoreLogic Flood, LERETA, ServiceLink), appraisal/AVM (CBCInnovis, Mercury Network, Global DMS), pricing engines (Optimal Blue, Mortech, Loansifter), closing/compliance (DocMagic, Asurity, ComplianceEase).

These are selected from within Point/PointCentral itself by an end user (loan officer/processor) — not something an outside developer integrates with via an API. Where no direct hook exists, data exchange falls back to scheduled MISMO 3.4 file import/export. Not applicable to our current or a hypothetical future integration, but useful context if a client asks why "Calyx already talks to X vendor."

5. Calyx Path — Certified Partner Integrations (Market Context, Not Experience.com-Specific)

Unlike Point/PointCentral, Path integrations are built and delivered as certified partner integrations, set up in coordination with Calyx or the partner vendor — not through public developer documentation. Known certified Path integrations (general market examples, unrelated to any Experience.com effort):

  • Optimal Blue — secondary marketing/pricing and eligibility APIs (first certified LOS integration with Optimal Blue's APIs, 2018).

  • NxtSoft (OmniConnect API) — connects Path users at banks/credit unions to core banking systems (2021).

  • DataVerify (DRIVE platform) — 4506-C tax transcript verification, SSA-89 SSN verification, flood zone determinations; supports XML-based company/end-user credentials.

  • CRM integrations — bidirectional LOS-CRM data sync (vendor-specific, referenced by Calyx customers).

There is no public OpenAPI spec, SDK, or self-service API key signup for Path. Building a new Path integration as an outside vendor requires going through Calyx's partner program (Section 6).

6. Calyx Industry Connect (CIC) — The Partner/API Onboarding Path

The most concrete "how do I actually get API access" answer across Point, PointCentral, and Path is Calyx Industry Connect (CIC) — Calyx's dedicated partner-onboarding platform.

  • Positioned to bridge lenders, partners, and technology providers via secure, scalable APIs with real-time data exchange and automated processes.

  • Designed to eliminate manual file export/import — originators can submit loans directly into a lender's platform instead of round-tripping files.

  • Public knowledge base (Confluence-hosted): calyxsoftware.atlassian.net/wiki/spaces/ICOKB.

  • Partner application form: forms.zohopublic.com/calyxsoftware/form/CICPartners/....

  • Direct contact: Tate Kesner — 214-710-2686, tate_kesner@calyxsoftware.com.

This is the appropriate starting point if Experience.com ever wants genuine programmatic/API-level access — for Path, or for a modernized Point/PointCentral integration — rather than the current PDS/CSV/SFTP workaround or pre-built vendor selection inside the product UI.

7. Feasibility Assessment (Answering V2DEV-29155's Acceptance Criterion)

Acceptance criterion (V2DEV-29155): "Integrate with Experience.com for customer business use cases." This is already satisfied for Calyx Point/PointCentral customers — see below — and not yet satisfied for Calyx Path customers.

Current state: Calyx Point/PointCentral is a working, production integration at Experience.com. It does not use Calyx's SDK or a live API — it uses a purpose-built Windows agent (PDS) that reads the client's Calyx SQL database directly, deduplicates against a local tracking DB, exports CSV, and SFTPs it to Experience.com. Setup is manual per client (1–2 hours), with two distinct onboarding flows depending on whether the client is Focus IT–hosted or self-hosted. This mechanism has been stable since at least 2020–2021, with documentation as recently as May 2025. This is the concrete answer to V2DEV-29155's "customer business use case" ask: onboarding a Calyx Point/PointCentral customer for post-closing survey delivery is a known, repeatable, ~1–2 hour process today.

Calyx Path is not integrated. A single 2020 requirements page shows an attempt was scoped (test account, API access, transaction creation) but never completed. Any request to support Path is effectively a greenfield build, not an extension of the existing Point work.

Recommendation:

  • For continued/expanded Point-PointCentral coverage: the existing PDS approach is proven and should remain the path of least resistance. The main open risks are the unresolved gaps in Section 2 (L.O. Email source ambiguity, firewall-restricted clients) rather than the integration model itself.

  • For any Path requirement: do not assume Point's PDS mechanism transfers. Path integration would need to go through Calyx Industry Connect (Section 6) or direct partner engagement with Calyx, similar to how Optimal Blue/NxtSoft/DataVerify became certified Path partners.

  • If a future need arises to write back into Point/PointCentral (not just read), the Point SDK (Section 4.1) — not direct SQL — is the compliant route, since it preserves Calyx's own validation and file-locking logic.

8. References