TX TREC Real Estate License Status Delta
Pricing
$10.00 / 1,000 license status changeds
TX TREC Real Estate License Status Delta
Watches named Texas real estate license holders in the official TREC registry and alerts only on a genuine status change (Revoked, Suspended, Probation, Surrendered, Expired). For brokerages, HR screening, title companies, insurers, due-diligence. Free when nothing changes.
Pricing
$10.00 / 1,000 license status changeds
Rating
0.0
(0)
Developer
Radu Furtuna
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
19 hours ago
Last modified
Categories
Share
Durable monitor for the official Broker and Sales Agent License Holder Information registry,
published by the Texas Real Estate Commission (TREC) as open data on data.texas.gov. Watch specific
license holders by their license number and get notified only when their license status genuinely
changes. No API key needed, no login, no captcha.
Source
https://data.texas.gov/resource/s7ft-44qi.json — the Socrata Open Data API for "Broker and Sales Agent
License Holder Information" (dataset id s7ft-44qi). Confirmed live 13.09.2026: 324,647 rows, updated
daily by TREC (updated field on the sample row: 2026-09-12T07:30:02). license_number is the
dataset's unique, permanent identifier for one license (format: digits + dash + letter suffix, e.g.
621981-B for a Broker Individual, 9017234-BB for a Broker Company, 1234567-SA for a Sales Agent) —
not the license holder's name, which is never unique. The status field observed live (13.09.2026) takes
at least these 18 values: Active (187,617), Expired less than 6 months (89,912), Inactive (38,591),
Expired more than 6 months (5,656), Revoked (1,137), Closed - Upgraded (651), Deceased (376),
Surrendered (227), Probation - Active (203), Suspended (192), Probation - Inactive (37),
Probated Suspension - Active (25), Military (11), Probated Revocation - Active (4), Deleted (4),
Inactive - Suspended (2), Archived (1), Probated Revocation - Inactive (1).
How it works
- Each
watchnames exactly one license holder bylicenseNumber(the TREC license number as published in the registry — look it up at trec.texas.gov/apps/license-holder-search/ if you only have a name). One watch = one point query ($where=license_number='<licenseNumber>') = one HTTP request per run. - The first check of a new watch establishes a baseline (no charge). Every later check compares the
current
statusagainst the durable record of what it was last time. - Billing is tied only to the
statusfield — not to name, address, related-license fields, or the routinelicense_expiration_daterenewal that shifts for every actively licensed holder as they renew. A status that changes and later reverts (e.g. suspended, then reinstated, then suspended again for a new violation) bills every genuine transition, not just the first one — never silently deduplicated against an earlier occurrence of the same status value. - Genuinely new (first found) or status-changed records are pushed to the dataset and billed once each
(
license-status-changed); a check that finds nothing new costs nothing beyond the fixed platform run cost.
Input
{"monitorId": "my-trec-watch","watches": [{ "watchId": "new-hire-jones", "licenseNumber": "621981-B" }],"notifyOn": "new_alerts","webhookUrl": "https://example.com/webhook"}
Add more license holders later under the same monitorId — each watch keeps its own independent history.
A watchId is permanently bound to the licenseNumber it first saw; pointing the same watchId at a
different license number later fails the run instead of silently mixing histories.
socrataAppToken is optional — data.texas.gov does not require a key for this dataset, but a free
Socrata app token from your own account raises the anonymous request-rate ceiling if you run many watches
across many monitors.
Output row (per change)
watchId, licenseNumber, changeType ("new"|"status_changed"), status, previousStatus, licenseType, fullName, suffix, firstName, middleName, lastName, county, originalLicenseDate, licenseExpirationDate, designatedSupervisorFlag, relatedLicenseType, relatedLicenseNumber, relatedLicenseFullName, relatedLicenseSuffix, relatedLicenseStartDate, agencyIdentifier, keyName, updated, monitorId, runId, discoveredAt, eventId, billedBilling
Pay-per-event: license-status-changed — charged only for a watch's first found record (baseline is free)
or a genuine status transition since the previous check. Failed/blocked checks are never charged.
Delivery/billing guarantee: at-most-once, not exactly-once
The right to perform an irreversible action (dataset write + PPE charge) is granted by the only atomic
primitive Apify offers — RequestQueue.addRequest(uniqueKey) → wasAlreadyPresent — in a separate
named queue that acts as a permanent journal (<prefix>-<monitorId>-claims). The Apify Key-Value Store
has no CAS, no conditional write and no ETag, so it can only ever be a diagnostic state machine, never
the source of at-most-once.
Concretely: for one computed event, delivery and charging each happen no more than once. If the run
dies after taking the claim, the event may be lost (it stays dataset_unknown/charge_unknown
and is never re-delivered) — but you will never be billed twice. That is a deliberate trade: "never
overcharge" beats "never lose a row".
Boundaries of the guarantee, stated honestly:
- Between the internal lease check and the dataset write/charge there is an unavoidable TOCTOU gap; what actually protects your money is the claim gate, not the lease.
- The guarantee holds for as long as the named claims queue exists. Anyone with account access can delete or recreate it via Console/API, which starts the journal from zero. This is a boundary of any durable storage, not a defect of the protocol.
- The guarantee applies from the build in which the claim gate was introduced onward. Older builds must
not keep running against the same
monitorId.
Important — read before relying on this for any hiring/transaction/compliance decision
This registry is a publication of license status, not a certification of good standing or a complete disciplinary record. TREC maintains its own authoritative records and enforcement files; the public dataset reflects what TREC has published, which can lag real-world disciplinary events. This actor is an informational monitor of CHANGES to that public publication — it is NOT a current "license to practice" certification, NOT a disciplinary-history lookup, and NOT legal advice. Always confirm directly at trec.texas.gov/apps/license-holder-search/ (or with TREC directly) before acting on any single entry — especially for hiring, brokerage sponsorship, transaction, or E&O insurance decisions.
Honest limits
- The durable dataset is a delivery-attempt log, not a guaranteed mirror of the default dataset.
Each row is written to the durable dataset first, then mirrored to the run's default dataset before
billing proceeds for that row. If the durable write succeeds but the default-dataset mirror write
fails (e.g. transient Apify storage error), the item is marked
dataset_unknown, billing for it is permanently blocked (fail-closed — we never charge for a row we can't confirm was delivered), and the run is not retried into re-creating that exact row. The durable dataset can therefore end up with a small number of orphan rows that were never mirrored and never billed. The default dataset is the canonical log of rows successfully written to this run's output (see itsrun_summaryrow) — but a default-dataset row does not by itself prove the row was billed: the row is written beforeActor.charge()runs, so if charging then fails or comes backcharge_unknown, the row is present but not confirmably paid.run_summary.eventsBilledand Apify's own billing ledger are the source of truth for confirmed payment, not the presence of a row in either dataset. - One watch = one license holder, one request. There is no bulk/roster mode — to track a brokerage's agents, add one watch per license holder (up to 30 per run). This keeps the network cost fixed and predictable regardless of the registry's total size (324k+ rows), and keeps each license's history independently auditable.
- A "not found" result on the very first check of a watch is reported honestly, not as an error —
coverage.watches[].matched: false. The registry does not delete records (confirmed live 13.09.2026: license holders withstatus=Deletedremain listed —Deletedis a published status VALUE, not a removed row; licenses expired in 1990, 2004, 2006, 2019, 2020, and 2021 are all still returned by a direct point query, each with a currentupdatedtimestamp from the daily refresh), so a typo'dlicenseNumberwill simply never match; it costs nothing and is safe to correct and retry under the samewatchId. - A license number that WAS found on a previous check but is NOT found on a later one is treated as
source_access_limitedfor that watch this run — no baseline/history update, no billing. Since the registry doesn't delete rows (see above — even decades-old surrendered/revoked/deleted licenses stay queryable), this should never happen from a genuine data change; it's the honest fallback if the source ever answers unexpectedly. - Billing tracks only the
statusfield, deliberately excludinglicense_expiration_date(which shifts routinely on every renewal for every actively licensed holder) and related-license/address/agency fields (which can change administratively — a new sponsoring broker, a office move — without any change to license status). Those fields are still delivered in every row for context. - We don't invent data: if the API ever returns something other than a bare JSON array, more than one row
for a single
license_number(violating the dataset's own uniqueness contract), or a row missinglicense_number/status, the run reports it honestly (source_access_limited) instead of guessing.
Author: OmniCoder (https://t.me/OmniCoder)