Illinois Business Entity Search

Purpose

Search the Illinois Secretary of State's Business Entity database (Corporations, Not-for-Profit Corporations, LPs, LLCs, LLPs) for matches to a query string — typically a business name — and return each result's file number, entity name, status, and entity type. Read-only.

When to Use

• Verify whether a business name is registered in Illinois.
• Bulk lookups by business name, registered agent, manager, secretary, president, or file number.
• Pre-filing name-availability checks before incorporating in Illinois.
• Anywhere you'd otherwise scrape the public Illinois business registry.

Workflow

The Illinois Business Entity Search is a server-rendered form-POST application protected by Akamai Bot Manager. Submission is hard-blocked from Browserbase remote sessions across every session config we tested (see Site-Specific Gotchas for the matrix). The form GET path loads fine, the form is fillable, and the Akamai sensor data POSTs to the dynamic /9lxW…/…/QYQ2wB-style endpoint DO fire — but _abck never transitions out of the unvalidated ~-1~…~-1~-1~-1 state, so the subsequent form POST is killed at the HTTP/2 layer (ERR_HTTP2_PROTOCOL_ERROR, Failed to fetch, navigation lands on chrome-error://chromewebdata/).

There is no public API alternative — the database is gated solely through this form per the site's "individual searches only, no bulk" policy.

Recommended approach when running in a non-Browserbase environment (e.g. real residential desktop Chrome, a non-headless instance with a warm user-data-dir, or an environment whose fingerprint Akamai accepts): drive the form via the browser flow below. From Browserbase remote sessions specifically, the skill will return a candidate failure documenting the anti-bot wall — see the "Akamai-block outcome" shape in Expected Output.

Browser flow

1. Open the search page: https://apps.ilsos.gov/businessentitysearch/. Wait for load and then sleep 8–12 seconds to let the Akamai sensor script (/akam/13/<id>) initialize window.bmak and complete its first sensor data POST to the dynamic /9lxW…/…/QYQ2wB-style endpoint.

2. Pick a search method — eight radio options, each posts a single character to searchMethod:

   Radio id	value	Use when …
   #name	s	Exact-prefix business name (most restrictive)
   #agentsearch	a	Registered Agent name
   #presidentsearch	r	Officer search — President
   #secretarysearch	c	Officer search — Secretary
   #managersearch	m	LLC Manager — reveals separate Last/First/Middle + Business Name fields (NOT the same searchValue field)
   #fileNumber	f	Direct lookup by 8-digit file number
   #keyWord	e	Keyword (matches a word in the name)
   #partialWord	p	Partial Word (substring match, the loosest)

   For a multi-word query like "smith ventures", p (Partial Word) is the right choice — it matches names containing both substrings. If p returns zero rows, fall back to e (Keyword), then s (Business Name).

3. Generate user-interaction signals before submitting — Akamai's sensor weights real keyboard/mouse events heavily. Click the input field, then browse type "smith ventures" (do not browse fill — fill skips keypress events). Wait 1.5–3s between steps.

4. Submit: click #btnSearch (the form's <input type="submit">). The form action is POST /businessentitysearch/businessentitysearch with hidden command=entitySearch&method=search plus the chosen searchMethod + searchValue.

5. Read the results page. On success the response is a server-rendered HTML table — one row per matching entity. Extract from the result table:

   • File Number (left-most column, also encoded in the per-row "detail" form-POST that loads the entity record).
   • Entity Name (typically all-caps as stored in the registry).
   • Status — ACTIVE, INACTIVE, DISSOLVED, NOT IN GOOD STANDING, etc.
   • Entity Type — CORP, NFP (not-for-profit corp), LLC, LP, LLP.

   The site does not expose stable detail-page URLs — each detail-link is a per-row form POST carrying the file number plus the same Akamai cookies. Read-only for this skill: do not click into detail pages.

6. Branch on URL after submit:

   • https://apps.ilsos.gov/businessentitysearch/businessentitysearch (or similar /businessentitysearch/... path) → normal results page; parse the table.
   • https://www.ilsos.gov/ (silent redirect) → Akamai rejected the request and bounced you to the ilsos.gov homepage. Retry from step 1 with a longer warmup (15s+), or surface the akamai_blocked outcome.
   • chrome-error://chromewebdata/ (ERR_HTTP2_PROTOCOL_ERROR) → the hard Akamai wall — the POST never reached the application server. Surface the akamai_blocked outcome.

7. If the table renders "No Records Found" / "No matching records": retry with the next-looser search method (p → e → s). If all three return empty, return total_results: 0.

Site-Specific Gotchas

• Akamai blocks Browserbase remote sessions on every config tested. We verified the POST is killed at the network layer (Failed to fetch from page-context fetch(), ERR_HTTP2_PROTOCOL_ERROR from click-based navigation) across this matrix:

  Session flags	Region	Result
  --verified --proxies	us-west-2	blocked
  --verified --proxies --solve-captchas	us-west-2	blocked
  --verified --proxies	us-east-1	blocked
  bare (no --verified, no --proxies)	us-west-2	blocked

  The page GET works fine (200 OK with rendered HTML), the Akamai sensor script loads, sensor-data XHRs fire, but _abck never transitions out of ~-1~…~-1~-1~-1 (the unvalidated state). Akamai's edge then silently RST's the POST stream. Do not waste time trying additional stealth knobs from Browserbase — the block is at Akamai's bot-validation layer, which Browserbase Verified mode does not pass on this domain.

• Mitigation for non-Browserbase environments: a real residential desktop Chrome with a warm profile (cookies, history, etc.) typically passes. Headless Chrome / Playwright with default args is also blocked. If you must run from automation, consider importing a valid _abck cookie from a human-driven session into your automation session (the cookie validates for ~30 minutes after a successful human submission).

• browse fill vs browse type: fill writes the value to the DOM directly and does not fire individual keypress events that Akamai watches. browse type (or browse click then individual keypresses) generates the events Akamai's sensor expects. Always prefer type on this form.

• form#index is intercepted by jQuery validate. The form's submit is wired through jQuery validate (submitHandler: function(form){ if($("form#index").valid()){ $("input[type=submit]").prop("disabled", true); form.submit(); } }). Calling document.getElementById('index') .submit() directly from browse eval will throw because validate overrides .submit. Use a real click on #btnSearch instead.

• GET requests with query params don't work as a backdoor: appending ?command=entitySearch&method=search&searchMethod=p&searchValue=... to the action URL produces a redirect loop (502 from browse cloud fetch --allow-redirects after 20 hops), or a silent redirect to https://www.ilsos.gov/ from the browser. The endpoint requires POST.

• No public JSON / REST API exists for this database. The Illinois Secretary of State's policy explicitly forbids bulk extraction: "The database is available to the public for individual searches only. This database may not be used to copy or download bulk information searches." There is no GraphQL, no /api/, no sitemap-indexed per-entity URL. The form is the only surface.

• Manager-search uses a different field set. Picking #managersearch hides #searchValue and reveals separate #maLastName, #maFirstName, #maMiddleIni, and #maBusinessName inputs (with an "Or" between the personal-name group and the business-name field). Validation: maLastName must be ≥3 chars, maFirstName must be ≥2 chars, and the personal-name vs business-name fields are mutually exclusive (filling one disables the other). The other seven search methods all use the single #searchValue field.

• searchValue is maxlength=30. Longer queries are truncated by the browser at the input level. Plan for this on long business names.

• Session JSESSIONID is short-lived (HttpOnly, SameSite=Lax, Path=/). The _abck Akamai cookie has a 1-year Max-Age but its validated state expires after ~30 minutes of inactivity, after which Akamai re-challenges.

• bazadebezolkohpepadr script-injected global is the Akamai sensor signature seed — observed as bazadebezolkohpepadr="556413745" in the page's inline script. It correlates with the sensor JS load. If this global isn't present, the sensor never initializes.

Expected Output

Four distinct outcome shapes:

// 1. Success — results returned
{
  "success": true,
  "query": "smith ventures",
  "search_method_used": "p",
  "total_results": 7,
  "results": [
    {
      "file_number": "12345678",
      "name": "SMITH VENTURES INC.",
      "status": "ACTIVE",
      "entity_type": "CORP"
    },
    {
      "file_number": "87654321",
      "name": "SMITH VENTURES LLC",
      "status": "DISSOLVED",
      "entity_type": "LLC"
    }
  ],
  "error_reasoning": null
}

// 2. Zero matches across all three fallback methods
{
  "success": true,
  "query": "smith ventures",
  "search_method_used": "s",
  "total_results": 0,
  "results": [],
  "error_reasoning": null
}

// 3. Akamai-block outcome (the documented failure path on Browserbase)
{
  "success": false,
  "query": "smith ventures",
  "search_method_used": "p",
  "total_results": null,
  "results": [],
  "error_reasoning": "akamai_blocked: POST /businessentitysearch/businessentitysearch returned ERR_HTTP2_PROTOCOL_ERROR — _abck cookie remained in unvalidated -1 state across 12s warmup + simulated user interaction. Browserbase Verified mode + residential proxies + us-east-1 region all blocked. Retry from a non-Browserbase environment with a warm Chrome profile or imported _abck cookie."
}

// 4. Form-validation error (e.g. empty searchValue, sub-3-char Manager Last Name)
{
  "success": false,
  "query": "",
  "search_method_used": "p",
  "total_results": null,
  "results": [],
  "error_reasoning": "validation_error: Serach Value is required"
}