Integration details
Description
Vitark connects ChatGPT to Indian case law and legislation for research grounded in source records. Search Supreme Court and High Court judgments and available tribunal and regulator decisions; find a case by name, case number, neutral citation or CNR; retrieve available judgment text; and look up statutory provisions. Explore similar cases, entity-linked cases and available citation links. Results include available source identifiers and retrieval limits. Judgment text may arrive in slices, and citation links may be unresolved candidates rather than verified later treatment. Verify the underlying text before relying on a result. Connect your existing Vitark account through secure sign-in. Successful substantive research calls use its credit balance; checking the balance is free. Vitark provides legal research information and does not replace advice from a qualified advocate.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Legal Research Engines
- Secondary Subcategories
- None listed
- Brand
- Vitark
- Access
- Account required
- First tracked
- 2026-09-16
- Tool count
- 9
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like

Competing in ChatGPT Legal Research Engines
View Category9 tools agents can invoke
Find cases using indexed judgment entities and metadata. Args: judge: Fuzzy judge-name filter. party: Fuzzy petitioner or respondent filter. advocate: Fuzzy counsel-name filter. act: Fuzzy Act-name filter; pair with section when known. section: Exact section token within the selected Act. judge_norm: Canonical judge norm returned by entity-suggest. party_norm: Canonical party norm returned by entity-suggest. advocate_norm: Canonical advocate norm returned by entity-suggest. act_norm: Canonical Act norm returned by entity-suggest. act_year: Enactment year to distinguish same-name Acts; requires act or act_norm. court: Court or forum name or alias. year_from: Inclusive decision-year lower bound. year_to: Inclusive decision-year upper bound. category: Extracted subject category. disposition: Extracted disposition. case_type: Exact case type. case_number: Docket, neutral citation, tribunal id, or CNR. page: One-based page number. page_size: Rows per page, from 1 through 50. Returns: {status, source_system, result_count, total, total_capped, page, page_size, results, entity_coverage}. `total` is the producer's count for the whole filter, capped at 1000 — `total_capped: true` means the real total is at least that, so page rather than quote the number. This index covers only the part of the corpus with entity extraction, so it is never exhaustive. `entity_coverage.status` is "complete" (the coverage block is authoritative), "unavailable" (coverage could not be read; say the answer is not exhaustive) or "not_covered" (the requested case or filter sits outside the extracted subset — real, just not indexed here). It is also topic-blind: it filters on who and what, never on what was held. `error_code` "missing_filter" means no filter was supplied, "invalid_act_year" means act_year arrived without act/act_norm, "section_requires_act" means `section` arrived without act/act_norm (a section is scoped inside an Act; resolve one with vitark_entity_suggest type="act"), and "capability_unavailable" means this index is down — never a finding about the person, Act or case. An error carrying `error_class` "caller_error" is a bad argument in this call: fix the argument and retry. Every other error is an outage, so do not retry it as though it were. Row extras: every row's `extras` may carry `url`, `citation`, `doc_kind`, `forum`, `court_type`, `treatment` (later judicial treatment — "not_checked" means nothing was examined, NOT that the case is good law), `text_available`, `chunk_offset` and `quality_flags`. An absent key is absent data, never a negative finding. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_cases_by
Check the Vitark credit balance of the signed-in account. Free to call. Credits are shared with the Vitark app account. Returns the total, reserved, and available credits for this account.
get_credit_balance
Find Indian cases similar to a reference case, identified by CNR. How it works: 1. Fetches the full judgement text for the reference CNR. 2. Uses an LLM to extract the core legal issue from the judgement. 3. Runs a semantic search over the vitark corpus with that issue as the query. 4. Filters out the reference CNR from the results. Use this when the user asks for "more cases like this", "similar precedents to X", "what else has dealt with this issue", etc. Args: cnr: The reference case CNR. top_k: Number of rows to return (default 10) — passages by default, judgments when group_by_case is true. group_by_case: Collapse the passages of one judgment onto a single row (best-ranked passage as the snippet, the rest under `additional_passages`) so `top_k` counts JUDGMENTS. Retrieval and ordering are unchanged; default false keeps the historical passage-level shape. Returns: - reference_cnr: the input CNR - extracted_issue: the core legal issue used for the search - query: the effective search query (same as extracted_issue) - source_system: "vitark" - result_count: number of ROWS returned - case_count: number of distinct judgments those rows cover — lower than result_count whenever a judgment contributed more than one passage - grouped_by_case: whether the rows are per-judgment - results: list of cases in the same schema as vitark_search Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_similar_cases
Find a judgment by party or case name, docket number, neutral citation, or 16-character CNR. This is a metadata lookup rather than semantic legal research. Name lookups check the complete catalog and an extracted-case subset. Complete-catalog party and title fields currently cover tribunal rows; the extracted subset adds Supreme Court and High Court names for about 20 percent of the corpus. A CNR can resolve directly to one record with `resolver: "cnr_lookup"`. Results include an opening `snippet` and may include a clean title and summary. Args: name: Party or case name, without conversational filler. Optional when case_number is supplied. case_number: Docket number, neutral citation, or CNR. Optional when name is supplied. court: Optional exact court name filter. year: Optional decision year. Returns: The envelope contains `match_count`, `match_definitive`, `resolver`, `notes`, `match_kind`, `match_confidence`, and `results`. Resolver values are `cnr_lookup`, `full_catalog`, `legacy_extracted_subset`, or `full_catalog+legacy_extracted_subset`. For a zero-result envelope, `match_definitive=true` records that every applicable lookup completed; false records incomplete coverage. The flag describes lookup coverage and does not grade a returned match. `pagination_incomplete` records an uninspected remainder. `named_lookup_failed` with error class `capability_unavailable` records that lookup was unavailable. `match_kind` can be `cnr`, `case_number`, `docket`, `party`, `query`, or `partial`; `match_confidence` can be `exact`, `high`, or `candidate`. Row `extras` may contain `cnr`, bench, judges, case type, petitioner, respondent, `url`, citation, `doc_kind`, forum, court type, `treatment`, text availability, chunk offset, and quality flags. A treatment value of `not_checked` records that later judicial treatment was not examined. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_case_find
Read Acts, cited cases, and approximate reverse citations for a judgment. Args: cnr: Canonical case identifier returned by another Vitark tool. Returns: {status, source_system, source_id, cnr, source_matched, acts_referred, cases_referred, citing_candidates, citing_candidate_count, entity_coverage, reverse_edges_resolved, text_available}. `acts_referred` and `cases_referred` are what THIS judgment cites. `citing_candidates` are judgments that appear to cite it, matched by cited CNR or by normalised title, so a title collision can put an unrelated case in the list. Each candidate carries `citation_matched` / `reverse_edge_resolved`: false means the edge itself was not confirmed, not that the candidate is fake. `reverse_edges_resolved` is true when every candidate resolved — including an empty list, where there is nothing left to resolve. `treatment` is the producer's own label: followed, relied_on, distinguished, overruled, referred, doubted, or "unknown" when extraction read the judgment and found no express statement. "not_checked" appears only when the producer supplied no treatment value at all — the field absent or null — which says the pipeline has not examined the case, not that the case is unmarked. Neither label is a finding that the case is still good law. `entity_coverage.status` "not_covered" means this CNR sits outside the entity-extraction subset: the judgment is real and readable through vitark_case_text, only its extracted relationships are missing, and `reverse_edges_resolved` is true because there is nothing left to resolve. `error_code` "capability_unavailable" means the citation index is down — a tool outage, never a finding about the case. An error carrying `error_class` "caller_error" is a bad argument in this call instead. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_case_citations
Fetch the FULL raw judgement text for a case. Use this when the user asks to read the actual reasoning, ratio, or verbatim content of a judgement, or when you need to quote a specific passage from the court's opinion. Args: cnr: The Case Number Reference (e.g. "ESCR010000971995"), or any reference vitark_case_find accepts — a Supreme Court neutral citation ("1995 INSC 98") or a docket number ("W.P.(C) 912/2025"). A non-CNR reference is resolved against the case-records database first; when it names exactly one judgment its text is returned with `resolved_from` set. offset: first character to read, for judgements longer than one 50,000-character slice. Pass the `next_offset` of the previous call to read on; omit it (0) for the beginning. Returns: - cnr: the case identifier the text belongs to - text: raw UTF-8 judgement text (up to 50,000 chars per call) - char_count: character count of this slice - truncated: true when more text remains after this slice - offset / next_offset: where this slice starts, and the offset to pass back to read the next one (null when nothing remains) - resolved_from: the reference given, when it was not a CNR When a reference names several judgments the result is {status: "error", error_code: "ambiguous_case_reference", candidates: [{cnr, title, court, year}]} — call this tool again with the CNR of the one you want. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_case_text
Resolve a person, party, Act, or place to an indexed canonical value. Args: type: Entity kind: judge, party, advocate, act, or place. q: At least two characters of the name to resolve. limit: Maximum suggestions, from 1 through 15. Returns: Suggestions with display value, canonical norm, type, and case count. Pass the norm to the matching ``*_norm`` cases-by filter. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_entity_suggest
Search Indian law: judgments, tribunal decisions and statutory text in one call. Supreme Court of India (38,021). High Courts (16,509,200 across 25 courts): Bombay High Court, High Court of Punjab and Haryana, Patna High Court, Allahabad High Court, Madras High Court, High Court of Kerala, High Court Of Rajasthan, High Court for State of Telangana, High Court of Karnataka, Orissa High Court, High Court of Madhya Pradesh, High Court Of Chhattisgarh, High Court of Jharkhand, High Court of Gujarat, Calcutta High Court, High Court of Delhi, Gauhati High Court, High Court of Andhra Pradesh, High Court of Himachal Pradesh, High Court of Uttarakhand, High Court of Jammu and Kashmir, High Court of Tripura, High Court of Manipur, High Court of Meghalaya, High Court of Sikkim. Tribunals and regulators (240,575): Customs, Excise and Service Tax Appellate Tribunal (CESTAT) — 78,366, 2021-2026 Debts Recovery Tribunal (DRT) — 63,903, 2018-2026 Securities Appellate Tribunal (SAT) — 42,534, 2006-2026 National Company Law Appellate Tribunal (NCLAT) — 24,206, 2021-2026 Insolvency and Bankruptcy Board of India (IBBI) — 15,505, 2021-2026 Securities and Exchange Board of India (SEBI) — 4,961, 2021-2026 Competition Commission of India (CCI) — 2,944, 2010-2026 Appellate Tribunal for Forfeited Property (ATFP) — 2,906, 2021-2026 Appellate Tribunal for Electricity (APTEL) — 2,851, 2008-2026 Telecom Disputes Settlement and Appellate Tribunal (TDSAT) — 1,279, 2001-2026 GST Authority for Advance Ruling (GST AAR) — 1,115, 2017-2026 Delhi Real Estate Regulatory Authority (DELHI RERA) — 5, 2024-2024 Listed with no documents yet (a search filtered to these returns nothing): Central Administrative Tribunal (CAT), Goods and Services Tax Appellate Tribunal (GSTAT), Income Tax Appellate Tribunal (ITAT), Insurance Regulatory and Development Authority of India (IRDAI), Maharashtra Real Estate Regulatory Authority (MAHARERA), National Company Law Tribunal (NCLT), National Green Tribunal (NGT) Statutes: Central Acts and the Constitution; Regulator Regulations (CBIC, CPCB, DFS, DGFT, IRDAI, LAW-COMMISSION, MCA, MOEFCC, RBI, SEBI, TRAI, TRIB-IBBI); state legislation for 36 states/UTs (Andaman and Nicobar Islands, Andhra Pradesh, Arunachal Pradesh, Assam, Bihar, Chandigarh, Chhattisgarh, Dadra and Nagar Haveli and Daman and Diu, Delhi, Goa, Gujarat, Haryana, Himachal Pradesh, Jammu and Kashmir, Jharkhand, Karnataka, Kerala, Ladakh, Lakshadweep, Madhya Pradesh, Maharashtra, Manipur, Meghalaya, Mizoram, Nagaland, Odisha, Puducherry, Punjab, Rajasthan, Sikkim, Tamil Nadu, Telangana, Tripura, Uttar Pradesh, Uttarakhand, West Bengal). Parameters: query the user's legal question, verbatim. courts court, tribunal or statute-collection names — display name, acronym or alias all resolve. Omit to search the whole corpus. With scope "all", court/forum names restrict the judgment branch while the statute branch remains eligible. Always pass an exact court the user named here, even when it remains in query text. Naming ONLY statute collections ("Maharashtra", "regulations") narrows the call to statutes; add a court or forum name to search judgments as well. For Act/section text constraints use vitark_statute_search. sources optional case-corpus list: "sc", "hc", "tribunals". year_from inclusive lower bound on the decision year. year_to inclusive upper bound on the decision year. scope "cases", "statutes" or "all" (default). limit maximum results per scope, 1-25 (default 15): at most `limit` case rows AND at most `limit` statute rows. Excerpts are capped, so ask for what you need — a small limit is a small response. decision_date_from / decision_date_to inclusive YYYY-MM-DD decision-date bounds, finer than year_from/year_to; cases only. cnr exact canonical case identifier, copied from an earlier envelope; cases only. act_year_from / act_year_to inclusive enactment-year bounds for statutes. ministry exact statute ministry filter. Returns one envelope: `results` (case rows, each with extras.source, extras.court_type, extras.forum, extras.year, extras.url) counted by `result_count`, and `statute_results` (statutory text) counted by `statute_count`. A scope="statutes" search returns no case rows, so `result_count` is 0 there and `statute_count` is the count to read. Also `statutory_provisions` (sections central to the answer), `source_mix`, `resolved_scope` (canonical courts, corpus types, years, collections, leg counts and deterministic support level), `candidates_reviewed`, `empty_corpora` (requested forums Vitark holds no documents from), `unresolved_courts` (requested names that matched no forum) and `notes` (plain-language advisories about how the request was read). `status` is complete, partial or error; `source_outcomes` identifies failed or incomplete source windows. A zero is a definitive no-match only when status is complete. `support_level` is strong, moderate, weak, none (nothing retrieved) or unavailable (nothing graded — the reranker did not run, not a low grade). `support_basis` names its scale, "rerank_relevance_not_legal_entailment" on case rows: passage match, never legal entailment. For ONE named case use vitark_case_find: a 0 is a real absence only with `match_definitive` true, else it was merely not located. Row extras: a case row's `extras` may carry `url` (source), `citation`, `doc_kind`, `forum`, `court_type`, `treatment` (later judicial treatment — "not_checked" means nothing was examined, NOT that the case is good law), `text_available` (via vitark_case_text), `chunk_offset` and `quality_flags`. An absent key is absent data, never a negative finding. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_search
Search statutory text with exact producer-supported filters. This tool performs one statute request and never invokes case search, case enrichment, or mixed-scope planning. Explicit constraints are forwarded unchanged and are never removed after a zero-result search. Exact Act + section lookups read the Act catalog directly, without semantic retrieval. Every row carries verbatim `section_text`; quote from that field, never from `snippet`. `snippet` holds the same text as a display excerpt and is clipped elsewhere in the system, so a long section read only from a snippet can be missing its later sub-sections. Only `section_text_complete: true` confirms the complete stored section. Any other row can be a search fragment: re-request it by `act_id` and `section_number` before claiming to have read the whole section. Args: query: Natural-language statute query. top_k: Upper bound on returned statute rows. act_id: Addresses one Act exactly by its stable identifier. Use it when a previous result carried an `act_id`, in place of guessing an act_slug string. act_slug: Exact Act slug. act_year_from: Inclusive Act-year lower bound. act_year_to: Inclusive Act-year upper bound. section_number: Exact section identifier. ministry: Exact ministry filter. collection: Collection filter — "central", "regulations", or a state name. Returns: A statute envelope with `status`, `source_outcomes`, `result_count` and `results`; `statute_results` and `statute_count` are aliases for mixed-search envelope consumers, and `case_count` is always 0 here. Each result carries `act_title`, `section_number`, a display `snippet`, the verbatim unclipped `section_text`, the Act's `act_id` (pass it back to address that Act exactly), `resolved_by` ("catalog" for an exact Act match, "vector" for a semantic one), `section_text_complete` (true only when the row is the complete stored section) and `pinned`. `pinned: true` means you supplied `section_number` with `act_id` or `act_slug` and the producer matched that exact Act and section from its catalog — the strongest identity this tool reports. `support_level` is strong (some row is pinned), weak (rows, none pinned) or none (no rows). `support_basis` is "catalog_identity_not_relevance": on this envelope the level grades whether the right Act and section were identified, NOT whether the section answers the question. The case envelopes use the same word for rerank relevance ("rerank_relevance_not_legal_entailment"), so read the basis before comparing two levels. Both fields appear at the top of the envelope and again inside `resolved_scope`, on either envelope. `candidates_reviewed` is the number of rows the leg reviewed before duplicates were collapsed, so it can exceed `statute_count`. `resolved_scope` reports `statute_collections` searched and `legs` {planned, ok, partial, partial_detail}, where `partial_detail` names each source that did not complete; its court fields stay empty here. `notes` carries producer advisories about how the request was read — for example that an `act_slug` was ignored in favour of the `act_id` you sent. Successful calls can spend credits from the signed-in Vitark account. Repeating a call can spend credits again.
vitark_statute_search
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Vitark alternatives on ChatGPT?
As of 2026-09-16, Vitark competes with AI Attorney, AL WAKEELO, Alizé, Appealbase, Açık Silivri Havadis, BIA Edge, CiteCheck, CiteLaw, CourtListener, Craime, Descrybe Legal Engine, DirectCase Legal Research, eCFR MCP, ElevenFlo, F-AI Contract Template Finder, Folium Jurisprudencia Chilena, Fontis, GovQuery, IAJUS, IFG, Juridata, Lawstronaut, Legal Data Hunter, Legalcode, LegisGraph, LegisRatio, Letra da Lei, LibreJustice, Midpage Legal Research, Nylon, OpenRegs: Regulatory Research, Policy Doctor, realLaw AI, Red Judicial, Remedy Legal, Simpliciter AI, Special Education Law, TaxGraph, TaxMCP, Trellis Law, Trifolia, Vasara in ChatGPT Legal Research Engines, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.