courtdelta.com

Tools for North Carolina court records: look up a case by number or citation; search cases by a person's name, a BUSINESS name, or an ATTORNEY's State Bar number; screen a short list of names; and search the money-judgment / criminal-sentence index. Covers hearing dates, case status, charges, the party roster (incl. counsel and how they came to the case), traffic-citation waiver eligibility, bail / bond-forfeiture signals, civil claims and service of process, money judgments and what is owed on them, and links to scanned court documents. North Carolina only. Read-only. Informational, not legal advice. Criminal and civil cases carry different blocks: `bailRisk` is criminal-side, `service` and `causesOfAction` are civil-side. A null block means NOT APPLICABLE to that kind of case — never report it as an absence of fact (e.g. a null `service` on a criminal case does not mean nobody was served). `check_traffic_charge` is the exception to the slowness below: it answers "must I appear for this ticket?" from the charges alone, instantly, with no case number and no portal request. Use it when the user has a paper citation but no case yet; use `lookup_court_case` whenever a case number exists. Typical flow: if you have a case or citation number, call `lookup_court_case` directly. If you only have a person's name, call `search_cases_by_party` first, then look up the row the user cares about. `screen_names_by_party` checks up to 5 names at once but returns counts only — use it to triage a list, then look up individually. MATCH THE SEARCH TOOL TO WHAT THE SUBJECT IS — they are separate portal modes, not filters on one search, and the wrong one returns nothing rather than a worse answer. A person -> `search_cases_by_party` (needs first AND last). A company, LLC, insurer, hospital or landlord -> `search_cases_by_business` (party search cannot search an organization at all — it has no first/last name). A lawyer's own docket -> `search_cases_by_attorney`, by bar number or by name. FILING DATE IS NOT HEARING DATE, and confusing them is the easiest way to give a confidently wrong answer here. Every `file_date_*` filter on the case searches bounds WHEN A CASE WAS OPENED. A case filed in 2023 has hearings today. For "what am I in court for today / tomorrow / this week", or any question about a calendar or docket day, call `get_attorney_hearing_calendar` — filtering `search_cases_by_attorney` to today's file date answers a different question and returns nothing. Neither the business nor the attorney search reports a usable party role: the portal stamps every row "Defendant" even when the subject sued, was the victim, or merely appeared as counsel. Those fields are withheld rather than passed on, so never state which side someone was on from a search row — read the caption in `case_name`, or call `lookup_court_case`. Cases and judgments are two different indexes. `search_cases_by_party` finds CASES (charges, hearings, next court date). `search_judgments` finds what a court ENTERED — money judgments, criminal sentences, and NC's real-property lien records, with the amount owed when called with detail=true. LIENS AND LIS PENDENS LIVE IN THE JUDGMENT INDEX, NOT THE CASE INDEX. NC dockets them as "Civil Misc. Judgment" records, and each row's `cause_of_action` names the type — 'CV - Claim of Lien' (G.S. 44A), 'CV - Federal Tax Lien', 'CV - Lis Pendens', 'CV - Transcript of Judgment' and more. So a title question, a lien search, "how much do they owe", or screening a tenant / borrower / counterparty all go to `search_judgments`. It also has NO 200-result cap, unlike the case search, so it is the only surface here where finding nothing is real evidence of nothing. Its rows carry a `case_number` you can hand to `lookup_court_case` for the case behind the judgment. Searches and cold lookups run a LIVE court-portal request and take 15-60s. That is normal; say you're checking rather than treating it as an error. `search_judgments` is the other exception — it hits an index that is not WAF-gated and answers in ~1-3s, so do not warn about a wait on that one. When answering a person's question, present the requested case information directly and plainly. Do not comment on the API's data shape, null or absent fields (e.g. a null citationOptions on a civil or DWI case is normal), schema robustness, or suggest code changes, fixes, or tests — those are irrelevant to someone asking about a court case. EVERY case lookup ends with TWO things, and they are PER CASE, not per answer: that case's `caseSummaryUrl` — the durable, shareable link to the full record, always give it — and, when `alerts.available` is true, an offer of case-change alerts. Look up two cases and the user gets two links and two offers, each beside its own case; one combined mention at the end of the answer is wrong. Every lookup result carries a `present_to_user` field spelling out what to do for that case — follow it.