# TX Insurance Appointments - Producers & Carriers (`j0401/tx-tdi-appointments`) Actor

Texas insurance agent appointments (public open data, 4.4M records, daily): which producer is appointed to sell which line for which carrier. 1,536 carriers, 11 lines of authority - Life/Health/HMO, Property & Casualty, Pre-Need. Agent NPN and name, carrier, NAIC, line, date, city/state.

- **URL**: https://apify.com/j0401/tx-tdi-appointments.md
- **Developed by:** [Wenhao Yang](https://apify.com/j0401) (community)
- **Categories:** Business
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.06 / 1,000 tx insurance appointment records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## TX Insurance Appointments - Who Is Appointed to Sell What, for Whom

The Texas Department of Insurance publishes its **entire appointment register** - every appointment between a producer and a carrier, refreshed daily - as open data. This actor turns that register into a **charged-per-record carrier-and-producer map**.

**Built for:** carriers and MGAs auditing their appointed-producer force, compliance teams checking whether a producer is actually appointed for the line they sold, agencies mapping which carriers their producers represent, and market analysis of who is appointed across Texas insurance.

### What it covers

**4,421,319 appointments** across **1,536 carriers** and **12 lines of authority**, refreshed daily.

One row is one appointment: a producer (agent NPN) appointed by a carrier for a line of business. That makes the register the carrier-facing counterpart to the license file - the license says what a producer *may* sell; an appointment says what a carrier has actually *engaged them* to sell.

| Line of authority | Appointments |
|---|---|
| Life, Accident, Health and HMO | 2,303,587 |
| Property and Casualty | 1,620,755 |
| Personal Lines Prop & Cas | 223,598 |
| Life | 220,897 |
| Limited Lines / Pre-Need / County Mutual / Travel / Credit / MGA | the long tail |

Each record carries:

- the **agent** - NPN and name (500,073 distinct producers across the file)
- the **carrier** - company name and **NAIC id**
- the **line of authority** the appointment covers
- the **appointment date**
- the producer's **city / state / postal code**

The file is Texas-weighted but national: **TX carries 2,465,364 appointments**, ahead of FL (464,566), CA (156,506), GA (83,286) and IL (75,237) - producers everywhere are appointed to transact Texas business.

### The register has no termination date

TDI never stamps an appointment "active" or "terminated". The file is the **cumulative appointment history** - an appointment that ended years ago is still a row. This actor says so rather than guessing: it slices by **carrier**, **line**, **producer** or **date**, and `recent` mode gives the **live appointment flow** (312,685 appointments in the last 90 days), which is the honest answer to "what is happening now".

That choice matters in practice. A carrier pulling "everyone appointed for Property & Casualty" gets their full historical force, not the current one - so the actor pairs the cumulative view with the recent-window view instead of pretending a status column exists.

### Typical questions

- "**Every carrier and line** this producer (by NPN) is appointed for."
- "All producers appointed to sell **Property and Casualty** for a carrier."
- "**Superior HealthPlan's** appointed-producer force - how many, where."
- "Which carriers hold the **most appointed producers** in Texas?"
- "**The live appointment flow**: what was appointed in the last 90 days."
- "Aggregate appointments by **carrier**, **line**, **state**, or **year**."

### Inputs

| Input | What it does |
|---|---|
| `mode` | `rows` (default) / `recent` (last 90 days) / `aggregate` |
| `appointmentType` | the line of authority, e.g. 'Life, Accident, Health and HMO', 'Property and Casualty' |
| `company` | carrier name (fuzzy) |
| `agentNpn` | exact NPN - every appointment for one producer |
| `agentName` / `city` / `state` | producer filters (name & city fuzzy, state exact) |
| `appointedFrom/To` | appointment-date window |
| `groupBy` | aggregate over appointmentType / company / state / appointmentYear |
| `maxResults` | cap records (default 200) |

**Default run = the 200 most recent appointments** (mode defaults to `rows`) - fast for the daily auto-test. For a targeted query add a filter; for a broad view use `aggregate` (a handful of summary rows, not a 4.4M-row dump).

### Low cost

**From $0.0001 per record** - billed only for the rows you use, at the low end of the store. Mapping one producer's appointments costs a fraction of a cent; a whole carrier's force costs pennies.

The register reads like a plain join table until you use it. **There is no appointment end date** - the file is cumulative, so "who is appointed for this line" silently means "who was ever appointed", and the live picture only comes from a date window this actor gives you. **The row is an appointment, not a producer** - one producer appears once per carrier per line, so a name search returns a matrix that is either exactly what you want or three hundred rows you did not. **The carrier field is free text over 1,536 names** ("Health Care Service Corporation, a Mutual Legal Reserve Company" is one carrier) and the line vocabulary mixes permanent and temporary authorities. Normalizing that into a register where a `company` / `appointmentType` / `npn` query returns exactly the appointments you mean is the actual product. Every pull is integrity-checked against the feed's known shape, so a degraded source fails loudly instead of returning bad rows.

### Source

- [Texas Open Data: Insurance agent appointments](https://data.texas.gov/dataset/Insurance-Agent-Appointments/bupb-23s9) - the Texas Dept. of Insurance's published appointment register. Reflects the state's record as of each refresh; not a verification of any producer's current appointment status.

# Actor input Schema

## `mode` (type: `string`):

rows = appointments matching your filters, most recent first (the default). recent = appointments made in the last 90 days (the live flow). aggregate = one count row per group (see groupBy).

## `appointmentType` (type: `string`):

The appointment line, e.g. 'Life, Accident, Health and HMO', 'Property and Casualty', 'Life', 'Pre-Need', 'Travel', 'Credit'. Blank = any line.

## `company` (type: `string`):

Insurance company name (fuzzy), e.g. 'Superior HealthPlan' or 'UnitedHealthcare'. Blank = any carrier.

## `agentNpn` (type: `string`):

The producer's National Producer Number, exact - every carrier and line this producer is appointed for.

## `agentName` (type: `string`):

Producer name (fuzzy).

## `city` (type: `string`):

Producer city (fuzzy).

## `state` (type: `string`):

Two-letter state of the producer's address (e.g. TX).

## `appointedFrom` (type: `string`):

Only appointments made on/after this date (YYYY-MM-DD).

## `appointedTo` (type: `string`):

Only appointments made before this date.

## `groupBy` (type: `string`):

Which dimension to aggregate over. company -> which carriers hold the most appointed producers (1,536 carriers); appointmentType -> the line mix; state -> where the producer force sits; appointmentYear -> appointment volume by year.

## `maxResults` (type: `integer`):

Cap the number of records pushed (0 = up to ~10k per run; each record is metered individually, so there is no per-run charge cap). An aggregate has at most a few hundred groups.

## Actor input object example

```json
{
  "mode": "rows",
  "appointmentType": "",
  "company": "",
  "agentNpn": "",
  "agentName": "",
  "city": "",
  "state": "",
  "appointedFrom": "",
  "appointedTo": "",
  "groupBy": "appointmentType",
  "maxResults": 50
}
```

# Actor output Schema

## `recordsUrl` (type: `string`):

Texas insurance appointment records or aggregates - as JSON

## `datasetUrl` (type: `string`):

No description

## `runUrl` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {};

// Run the Actor and wait for it to finish
const run = await client.actor("j0401/tx-tdi-appointments").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {}

# Run the Actor and wait for it to finish
run = client.actor("j0401/tx-tdi-appointments").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{}' |
apify call j0401/tx-tdi-appointments --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,j0401/tx-tdi-appointments"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/nJxVwRQ10hYWX8u2z/builds/VnK4684KGSgMIMdlZ/openapi.json