Texas Taxable Entity Search — Comptroller Franchise Tax Status

Search the Texas Comptroller's public franchise-tax account-status registry (mycpa.cpa.state.tx.us) by entity name, taxpayer number, or Texas Secretary of State (SOS) file number. Returns the official record: right-to-transact-business status, SOS registration status, registered agent, mailing address, and — when on file — officer/director/general-partner records from the entity's most recent Public Information Report (PIR).

Typical use: verify a Texas-registered company's standing before doing business with it, find its registered agent for service of process, or confirm the officers/managers on file for a compliance or lead-generation workflow.

Input

Field	Type	Default	Description
searchNames	string[]	["Whataburger Restaurants LLC"]	Entity names to search. Each name is one search.
searchTaxpayerIds	string[]	[]	Exact Comptroller Taxpayer Numbers (11-digit) or Federal EINs (9-digit). Faster and unambiguous — use when you already know the number.
searchFileNumbers	string[]	[]	Exact Texas SOS file numbers (6–10 digits).
maxResultsPerSearch	integer	20	Cap on matching entities returned per name search. Taxpayer-number and file-number searches always return at most one match.
fetchDetails	boolean	true	Fetch each match's detail record for mailing address, right-to-transact/SOS status, registered agent, and officers. If false, only the search-result summary fields are returned (one fewer request per entity).
maxItems	integer	100	Overall cap across all searches combined. 0 = unlimited.
proxyConfiguration	object	Apify Proxy, RESIDENTIAL, US	Standard Apify Proxy input. The actor works out of the box — no proxy key or credentials of your own are required.

At least one of searchNames / searchTaxpayerIds / searchFileNumbers must be non-empty. A name that is too broad (matches hundreds of entities) is rejected by the registry itself — narrow the name and re-run; this is logged as a warning per term, not a hard failure of the whole run.

Output fields

One record per matched entity. Fields marked "detail" only populate when fetchDetails is true (default) and the detail fetch succeeds.

Field	Source	Description
search_query	input	The name/number that produced this record
search_type	input	name, taxpayerId, or fileNumber
taxpayer_id	search+detail	Texas Comptroller Taxpayer Number
fei_number	detail	Federal EIN, when on file
name	search+detail	Official taxable-entity name on file
dba_name	detail	Doing-business-as name, if any
mailing_address	detail	Full mailing address, single line
mailing_address_zip	search	Mailing ZIP (always populated, even without detail)
right_to_transact_tx	detail	ACTIVE = franchise-tax account status is in good standing; a non-ACTIVE value signals the right to transact business in Texas is forfeited/ended
state_of_formation	detail	Jurisdiction of formation
sos_registration_status	detail	SOS registration status (updated each business day)
effective_sos_registration_date	detail	Effective date of SOS registration
sos_file_number	detail	Texas SOS file number
registered_agent_name	detail	Registered agent name — see PII note below
registered_office_address	detail	Registered agent's office address
officers	detail	Array of {name, title, active_year, address, city, state, zip, source} — see the standalone PII-granularity section below
officer_count	detail	Number of officer/director/general-partner records found
report_year	detail	Year of the most recent Public Information Report on file
last_updated	detail	Timestamp the Comptroller's system last refreshed this record
detail_url	derived	Direct link to the entity's page on comptroller.texas.gov
parse_confidence	derived	high / medium / low — see below

parse_confidence is high when the core search fields (name, taxpayer ID) are present and the detail fetch enriched the record with a registered agent; medium when core fields are present but detail enrichment is missing or thin (e.g. fetchDetails: false); low if even the core search-row fields are missing (an unrecognized API response shape).

⚠️ PII disclosure — officer/director records carry a full home or mailing street address

This is the most sensitive personal-data field in this actor and it is called out here on its own, not folded into a general description.

The officers array (sourced from each entity's Public Information Report, filed with and disclosed by the Texas Comptroller / Secretary of State) can carry, for each officer, director, or general partner: their full name plus a full street address, city, state, and ZIP code (fields AD_STR_POB_TX / CITY_NM / ST_CD / AD_ZP in the source data). For a large company this address is typically the corporate headquarters. For a smaller entity where an individual serves in their own capacity, this can be that individual's home or personal mailing address — a materially higher granularity of personal information than a bare name.

This is the same legal basis as this fleet's other business-registry actors (a legally-mandated public state filing, not personal data collected from a private source) — Texas law requires this disclosure precisely so the public, courts, and counterparties can identify and reach a company's responsible officers. The difference here is the address granularity: unlike a bare-name-only registry, this source's officer records routinely include a full street address alongside the name. Buyers using this actor for outreach, compliance, or due-diligence should be aware of that granularity before using the officers field — this is standard, already-public Texas state data, not a private source, but it is more identifying than a name alone.

The registered_agent_name field carries the same general pattern as this fleet's other SOS-registry actors: a business name for filings that use a registered-agent service company, or a natural person's name (paired with registered_office_address) for filings where an individual serves as their own registered agent.

Charge event

This actor bills per matched entity record delivered:

• entity-record — charged once per record pushed to the dataset (whether or not officers populated for that record — the right-to-transact status, SOS status, and registered agent fields are the JTBD-critical payload on every record regardless of entity type or officer-disclosure history).

Notes

• Officer/director coverage varies by entity and filing history — not every active entity has an officer array on file (e.g. no PIR filed yet, or a entity type/report combination the Comptroller doesn't track officers for). An empty officers array with a populated registered_agent_name and right_to_transact_tx is still a high-confidence record — officer coverage is a registry-completeness fact, not a parser gap.
• A taxpayer-number or SOS-file-number search is exact-match and unambiguous — prefer it whenever the number is already known.
• The registry itself rejects an overly broad name search (HTTP 413, "Search will return N entries. Please refine search by Entity Name.") rather than returning a huge unfiltered list — this actor treats that as "no records for this term" and logs the registry's own message so the caller knows to narrow the name, rather than silently truncating or retrying.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.