TX Board of Nursing License Status Delta

Durable monitor for the two official Texas Board of Nursing (TX BON) bulk registries — RN-All (Registered Nurses) and VN-All (Vocational/Licensed Vocational Nurses) — published as open data on data.texas.gov. Watch specific nursing licenses by license number and get notified only when the license status or a board disciplinary-action flag genuinely changes. No API key needed, no login, no captcha.

Source

Two Socrata Open Data API datasets, identical schema, disjoint license pools:

• RN-All: https://data.texas.gov/resource/tgb2-j935.json — 793,555 rows (confirmed live 13.09.2026)
• VN-All: https://data.texas.gov/resource/yjie-tuwv.json — 318,084 rows (confirmed live 13.09.2026)

license_number is a plain integer, unique within each pool independently (RN license 621981 and VN license 621981 are two different people) — confirmed live via the Socrata schema (dataTypeName: "number" for both datasets), which is why every watch names both a licenseType (RN or VN) and a licenseNumber. Updated monthly (Last-Modified observed 01.09.2026 at check time — this is a property of the source, not a limitation of this actor).

license_status observed live (13.09.2026) takes at least these 12 values (RN counts shown): CURRENT (C) (435,951), DELINQUENT (D) (207,318), INACTIVE (I) (99,860), DECEASED (E) (32,081), RETIRED - INACTIVE (Z) (9,320), REVOKED (R) (3,296), VOL.SURRENDER (V) (2,629), VOLUNTEER RETIRED (W) (2,194), NLC LICENSE - TX INVALID(Y) (450), SUSPENDED (S) (402), Current RENEWAL DENIED (K) (53), NOT CURRENT - SEE ENF (X) (1). VN-All uses the same value set with different frequencies.

A separate, independent disciplinary signal: current_board_action (a real boolean) and date_of_board_action_imposed. Confirmed live 13.09.2026: a license can carry license_status=CURRENT (C) (fully current) and current_board_action=true at the same time — a board action (reprimand, conditions, supervision order) does not always change the plain-text license status. This actor treats a change in either license_status or current_board_action/date_of_board_action_imposed as billable — watching license_status text alone would silently miss board actions imposed on an otherwise "current" license.

How it works

1. Each watch names exactly one nursing license by licenseType (RN or VN) + licenseNumber — look it up at bon.texas.gov/licensure_verification.asp if you only have a name. One watch = one point query ($where=license_number=<N> against the RN or VN dataset selected by licenseType) = one HTTP request per run.
2. The first check of a new watch establishes a baseline (no charge). Every later check compares the current combination of license_status + current_board_action + date_of_board_action_imposed against the durable record of what it was last time.
3. Billing is tied to that combination — not to name, address, employment, education, or the routine date_of_last_renewal/lincense_expiration_date fields that shift 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.
4. Genuinely new (first found) or changed records are pushed to the dataset and billed once each (nursing-license-status-changed); a check that finds nothing new costs nothing beyond the fixed platform run cost.

Input

{
  "monitorId": "my-nursing-watch",
  "watches": [
    { "watchId": "new-hire-jones", "licenseType": "RN", "licenseNumber": "621981" }
  ],
  "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 (licenseType, licenseNumber) pair it first saw; pointing the same watchId at a different license number OR a different license type later fails the run instead of silently mixing histories.

socrataAppToken is optional — data.texas.gov does not require a key for these datasets, 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, licenseType (RN|VN), changeType ("new"|"status_changed"), licenseStatus, previousLicenseStatus, currentBoardAction, previousCurrentBoardAction, dateOfBoardActionImposed, lastName, firstName, middleName, gender, ethnicity, licenseStatusDate, licenseExpirationDate, texasLicenseIssuanceDate, countyOfResidence, employmentStatus, primaryPracticeSetting, primaryPracticePositionType, primarySpecialty, highestDegree, basicNursingEducation, currentAdvancedPracticeRecognition, stateOfOriginalLicensure, dateOfLastRenewal, dateOfLastUpdate, nameOfBasicNursingSchool, graduationDateFromNursingSchool, placeOfEmployment, monitorId, runId, discoveredAt, eventId, billed

Billing

Pay-per-event: nursing-license-status-changed — charged only for a watch's first found record (baseline is free) or a genuine change in license_status and/or current_board_action/date_of_board_action_imposed 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/staffing/compliance decision

This registry is a publication of license status, not a certification of good standing or a complete disciplinary record. The Texas Board of Nursing maintains its own authoritative enforcement files; the public bulk dataset reflects what TX BON has published, which is updated only monthly (not daily) and 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/HR advice. Always confirm directly at bon.texas.gov/licensure_verification.asp (or with TX BON directly) before acting on any single entry — especially for hiring, staffing placement, credentialing, or compliance 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. a transient Apify storage error interrupts the run between the two writes), 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 does not retry 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 its run_summary row) — but a default-dataset row does not by itself prove the row was billed: the row is written before Actor.charge() runs, so if charging then fails or comes back charge_unknown, the row is present but not confirmably paid. run_summary.eventsBilled and 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 nursing license, one request. There is no bulk/roster mode — to track a whole unit or staffing pool, add one watch per license (up to 30 per run). This keeps the network cost fixed and predictable regardless of the registry's total size (793k+ / 318k+ 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. Neither registry deletes records (confirmed live 13.09.2026: decades- old DECEASED (E) licenses issued in 1927/1951 are still returned by a direct point query, each with a current date_of_last_update from the monthly refresh), so a typo'd licenseNumber or wrong licenseType will simply never match; it costs nothing and is safe to correct and retry under the same watchId.
• A license number that WAS found on a previous check but is NOT found on a later one is treated as source_access_limited for that watch this run — no baseline/history update, no billing. Since neither registry deletes rows (see above), this should never happen from a genuine data change; it's the honest fallback if the source ever answers unexpectedly.
• Billing tracks license_status + current_board_action + date_of_board_action_imposed only, deliberately excluding date_of_last_renewal/lincense_expiration_date/date_of_last_update (which shift routinely on every renewal for every actively licensed holder) and employment/education/address fields (which can change administratively without any change to license standing). Those fields are still delivered in every row for context.
• Update cadence is monthly, not daily — this is a property of the source (TX BON), not a limitation of this actor. Running this monitor more than once a month against the same watches will typically find nothing new between refreshes.
• 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 missing license_number/license_status/current_board_action, the run reports it honestly (source_access_limited) instead of guessing.

Author: OmniCoder (https://t.me/OmniCoder)