Building an SDK over LoneStarAgent ONE's net-sheet portal

PalmAgent Software publishes LoneStarAgent ONE as the Texas edition of its national closing-cost calculator: city- and county-coded title premiums, recording fees and seller-side prorations preloaded for the ~254 Texas counties, plus a saved-estimate ledger that an agent uses to send branded buyer estimates and seller net sheets to clients. The data a brokerage wants to integrate is not the calculator math — that is well-documented in the Texas Department of Insurance Basic Manual — but the per-agent stream of saved estimates, branded PDFs and county-coded line items the app holds against the agent's account. The cleanest way to pipe that into a CRM or transaction-management stack is a small SDK over the agent's authenticated session.

What the app actually holds

Most of LoneStarAgent ONE looks like a calculator from the outside, but a working integration treats five domains as the interesting surfaces. They are described here as the app names them where the public-facing copy is clear; the rest are confirmed during the build against a consenting agent account.

Routes to the data

Three routes apply here. They are not interchangeable, and one of them is what we would actually ship.

1. Authorized session integration against the PalmAgent portal

LoneStarAgent ONE is the mobile face of a web portal at palmagent.com that holds the same agent ledger. With the agent's authorization, a small SDK signs in as that agent, calls the same internal endpoints the web UI uses, and returns normalized records. Effort is one to two weeks for a first drop. Durability is good for as long as PalmAgent does not restructure its portal; we monitor and re-cut the SDK when they do. This is the route we would recommend for a brokerage build.

2. Protocol analysis of the mobile app's traffic

Where the mobile app exposes endpoints the web portal does not (mobile-only PDF rendering paths have shown up on related PalmAgent apps such as PalmAgent ONE and FidelityAgent ONE), we run an authorized protocol analysis of the Android or iOS app's traffic and add those surfaces to the SDK. We do this only against a consenting agent's installation; the captured behavior is documented in the build report.

3. Native export by the agent

The portal lets the agent download an estimate as a PDF or email it to the client. For a small brokerage with two or three agents, this is sometimes enough, and we will say so. For anything multi-tenant or CRM-bound the manual route does not scale; the SDK route does.

What is in the build

The deliverable is a working Python or Node.js client and the surrounding scaffolding, not a paper specification mailed back to you. In order:

• A typed SDK class for the net-sheet endpoint (seller_net_sheet, buyer_estimate, list_saved, get_pdf), in Python 3.11+ and Node.js 20+ flavours, against the agent's authenticated session.
• Cursor-paged backfill for the saved-estimate ledger, with throttling so the agent's account does not look anomalous to PalmAgent's portal.
• A PDF retrieval helper that streams the branded seller net sheet straight into the brokerage CRM's attachments bucket.
• A webhook handler stub for the brokerage CRM's "estimate saved" hook, plus a polling worker for the reverse direction (PalmAgent does not expose outbound webhooks at the time of writing, so the worker is what runs in production).
• An automated test harness that runs the round-trip — sign in, list saved, fetch one PDF, log out — against a sandbox agent account on every CI run.
• An OpenAPI document describing the SDK's outer surface, so the rest of the brokerage's services can generate clients of their own.
• A short auth-flow and protocol report (cookie chain, CSRF surface, session-refresh cadence, county-code mapping notes).
• A one-page data-retention and access-log memo so the integration sits cleanly inside the brokerage's compliance file.

A working snippet

The shape below is illustrative; field names and the exact auth surface are confirmed during the build. The Python flavour reads as follows.

from decimal import Decimal
from palmagent_sdk import PalmAgentClient

client = PalmAgentClient(
    session_cookie=os.environ["PA_SESSION"],
    base_url="https://app.palmagent.com",
    user_agent="brokerage-sync/1.0 (+ops@yourbrokerage.com)",
)

# One seller net sheet for a Harris County listing
sheet = client.seller_net_sheet(
    county="HARRIS",
    sale_price=Decimal("450000"),
    existing_loan_payoff=Decimal("182500"),
    closing_date="2026-07-15",
    title_partner="StewartTitle",
    agent_branding=True,
)

print(sheet.proceeds_to_seller)        # Decimal — net to seller
for line in sheet.line_items:
    print(line.category, line.amount)  # title_premium, escrow, recording, taxes, ...
print(sheet.pdf_url)                   # short-lived signed URL for the branded PDF

# Daily delta — pull anything saved since the last cursor
for est in client.iter_saved(since_cursor=last_cursor):
    crm.upsert_estimate(est)

# A 401 here means the session aged out; the SDK re-authenticates and retries once.

Engineering notes for this app

Three things we account for in the build that a generic closing-cost integration would miss.

• TDI rate revisions. Basic premium rates in Texas are set by the Commissioner of Insurance and revised on hearing — the most recent change took effect 1 March 2026 at a 6.2% reduction, per the Texas Department of Insurance. We do not duplicate the rate table on our side; the SDK reads the premium from a fresh net-sheet call so the integration is consistent with what the agent sees, and we ship a regression test that flags divergence if a future TDI hearing moves a known reference quote.
• County-specific recording and tax behavior. Recording fees and prorated taxes vary across Texas counties, and a handful of municipalities layer in additional charges. We confirm during onboarding which counties and cities a brokerage actually closes in, then verify that the SDK's county codes resolve to the same line-item set PalmAgent computes inside the app — so a Harris County estimate from the integration matches a Harris County estimate produced manually.
• Client PII inside saved estimates. Net sheets carry buyer and seller names, addresses and contract prices. We scope the build to the agent's own ledger under their authorization, never to other agents on the same brokerage account, and every read goes through a logged path so the brokerage can produce an access trail for the Texas Data Privacy and Security Act file if asked.

Authorization, regulation and what we keep clean

The dependable basis for the integration is the agent's own authorization over their PalmAgent account, with the brokerage as the contracting party. Two regimes touch the work and are worth naming because they shape design choices, not because they are abstract.

At the federal layer, the TILA-RESPA Integrated Disclosure rule (TRID) is what eventually replaces these line items with the lender's Loan Estimate and Closing Disclosure. The SDK's job is not to produce TRID disclosures — it is to feed accurate pre-contract estimates into a brokerage workflow that the lender's TRID forms will later reconcile against. We make that reconciliation field-by-field easy by normalizing the SDK's line-item categories to the Closing Disclosure's section letters.

At the state layer, title premium and closing services in Texas are promulgated by the Texas Department of Insurance under the Insurance Code §2703.151 basic-manual regime; we cite the TDI rate sheet directly in the build report so the brokerage's compliance team has the source one click away. Client PII inside saved estimates is handled under the Texas Data Privacy and Security Act framework: data minimization in transit, NDA where the engagement calls for one, and an access log for the brokerage's file.

How brokerages actually use this

• CRM-attached estimates. When an agent saves a seller net sheet in LoneStarAgent ONE, it appears the next day as an estimate record on the listing inside the brokerage CRM, branded PDF attached.
• Office-wide audit. A broker pulls a month of saved estimates across the office and checks that every estimate that became a contract is on file — a workflow that lives in spreadsheets today and reads as a daily sync once the SDK is wired in.
• Title-partner reconciliation. The estimate's title-partner field is matched against the title company that actually closed; mismatches are surfaced for the office manager.
• Transaction-management handoff. The SDK's normalized line items feed a Texas-specific transaction-management platform so the agent does not retype the numbers into a second tool.

Sources checked for this brief

Findings here are anchored to four sources opened on 3 June 2026: the Google Play listing for LoneStarAgent ONE (publisher, current package identifier and feature copy), the Texas Department of Insurance Title Insurance Basic Manual landing page (regulatory framework for promulgated premium and closing-services rates), the TDI 2026 Title Insurance Premium Rate schedule (current effective rate basis), and TitleTap's PalmAgent integration partner page (corroborating partner-portal integration patterns used elsewhere). Open in a new tab:

• LoneStarAgent ONE on Google Play
• Texas Title Insurance Basic Manual (TDI)
• Texas Title Insurance Premium Rates, effective 1 March 2026
• TitleTap — PalmAgent integration partner page

OpenFinance Lab · integration engineering notes, 3 June 2026.

Adjacent apps a brokerage usually has on the shortlist

Most Texas brokerages do not run LoneStarAgent ONE alone; an integration that wires it into the back office often touches the same apps an office considered before settling on PalmAgent. None are competitors of OpenFinance Lab — they are the rest of the ecosystem we plug into. Plain names, neutral notes:

• PalmAgent ONE — the national edition by the same publisher, same saved-estimate model, different preloaded rate tables.
• AustinTitleAgent ONE — a PalmAgent-built branded edition for an Austin-area title office, sharing the underlying ledger shape.
• ATAAgent ONE — another PalmAgent-built branded edition for a Texas title company; useful as a reference when an office runs both.
• CTOAgent ONE — a PalmAgent-built branded edition for a Florida title office; same SDK techniques apply against its portal.
• FidelityAgent ONE — the Fidelity-branded edition by PalmAgent, common at offices that already partner with Fidelity National Title.
• TitleCapture — a competing closing-cost and net-sheet platform with a wider calculator catalog and lead-capture widgets.
• CostsFirst — First American's own closing-cost and net-sheet calculator across desktop and mobile.
• WFG Seller Net Sheet — the WFG National Title version of the seller-side calculator, frequently used in Texas refinances.
• TitleSmart Sellers Net Sheet — a title-company-branded net-sheet calculator that sometimes appears alongside PalmAgent in dual-vendor offices.

FAQ

How does the SDK keep an agent's session alive between net-sheet syncs?

PalmAgent's portal authenticates against the agent's signed-in account, so the SDK persists the session cookie under the agent's authorization and refreshes it on a schedule. The refresh runs ahead of session timeout so a long-running brokerage sync does not need a human to log in again. We test the refresh cycle against a consenting agent account during the build.

Can two agents on different PalmAgent subscriptions be wired through one integration?

Yes. The SDK is multi-tenant by design: each agent's session is held under their own credentials and never crossed with another agent's. If the two agents are on different PalmAgent plans (for example free ONE versus ONE Premium), the available endpoints can differ — we map both per-account during onboarding and route each agent's calls to the surfaces their plan actually exposes.

What is the cleanest way to pull historical net sheets into our brokerage CRM?

A cursor-paged backfill against the agent's saved-estimate list, then an incremental delta on a daily cadence. The SDK exposes both as one call surface; the brokerage CRM only sees normalized records (transaction, buyer, seller, county, line items, branded PDF URL). The historical pass is rate-limited so PalmAgent's portal is not hammered.

What happens when the Texas Department of Insurance reprices title premiums?

PalmAgent updates its in-app tables when TDI publishes a new schedule; the most recent change took effect 1 March 2026 with a 6.2% reduction to basic premium rates per TDI. The SDK does not duplicate that table — it reads the value from a fresh net-sheet call so the integration stays consistent with what the agent sees in the app. Our build includes a small regression test that flags a divergence if a future TDI change shifts a known reference quote.

If you want to move on this: a first drop — Python or Node.js SDK, the backfill worker, the test harness and the protocol map — runs one to two weeks from a signed engagement. Source-code delivery starts at $300 and is paid after delivery once you are satisfied with the build, or you can call our hosted endpoints and pay only for the calls with no upfront fee. Either way, the next step is one message to our contact desk with the app name, your agent-count, and the brokerage CRM you would like it wired into.