# EDGAR Entities Database API > Search EDGAR filing entities by CIK, name or various criteria using the EDGAR Entities API. Retrieve information about registrants that have filed with the SEC through the EDGAR system since 1994, including filer category, auditor details, business address, and more. Source: https://sec-api.io/docs/edgar-entities-database-api The EDGAR Entities API provides search access to a database of all entities that have filed with the SEC through the EDGAR system since 1994. The database includes all filing entity types, also known as registrants, including operating companies (e.g., publicly listed companies), investment managers, business development companies, and more. Data sample · EDGAR entities | Name | Filer category | SIC | Incorporated in | Fiscal year end | Location | Auditor | Latest ICFR audit | Well-known seasoned issuer | Emerging growth | Shell company | CIK | IRS no. | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Tesla, Inc. | Large Accelerated Filer | 3711 MOTOR VEHICLES & PASSENGER CAR BODIES | TX | 1231 | AUSTIN, TX | PricewaterhouseCoopers LLP | 2026-04-30 | Yes | No | No | 1318605 | 912197729 | | JPMORGAN CHASE & CO | Large Accelerated Filer | 6021 NATIONAL COMMERCIAL BANKS | DE | 1231 | NEW YORK, NY | PricewaterhouseCoopers LLP | 2026-02-13 | No | No | No | 19617 | 132624428 | | Walmart Inc. | Large Accelerated Filer | 5331 RETAIL-VARIETY STORES | DE | 0131 | BENTONVILLE, AR | Ernst & Young LLP | 2026-03-13 | Yes | No | No | 104169 | 710415188 | | Meta Platforms, Inc. | Large Accelerated Filer | 7370 SERVICES-COMPUTER PROGRAMMING, DATA PROCESSING, ETC. | DE | 1231 | MENLO PARK, CA | Ernst & Young LLP | 2026-01-28 | Yes | No | No | 1326801 | 201665019 | | AMAZON COM INC | Large Accelerated Filer | 5961 RETAIL-CATALOG & MAIL-ORDER HOUSES | DE | 1231 | SEATTLE, WA | Ernst & Young LLP | 2026-02-05 | Yes | No | No | 1018724 | 911646860 | | Alphabet Inc. | Large Accelerated Filer | 7370 SERVICES-COMPUTER PROGRAMMING, DATA PROCESSING, ETC. | DE | 1231 | MOUNTAIN VIEW, CA | Ernst & Young LLP | 2026-02-04 | Yes | No | No | 1652044 | 611767919 | | Apple Inc. | Large Accelerated Filer | 3571 ELECTRONIC COMPUTERS | CA | 0926 | CUPERTINO, CA | Ernst & Young LLP | 2025-10-31 | Yes | No | No | 320193 | 942404110 | | NVIDIA CORP | Large Accelerated Filer | 3674 SEMICONDUCTORS & RELATED DEVICES | DE | 0131 | SANTA CLARA, CA | PricewaterhouseCoopers LLP | 2026-02-25 | Yes | No | No | 1045810 | 943177549 | | EXXON MOBIL CORP | Large Accelerated Filer | 2911 PETROLEUM REFINING | NJ | 1231 | SPRING, TX | PricewaterhouseCoopers LLP | 2026-02-18 | Yes | No | No | 34088 | 135409005 | | MICROSOFT CORP | Large Accelerated Filer | 7372 SERVICES-PREPACKAGED SOFTWARE | WA | 0630 | REDMOND, WA | DELOITTE & TOUCHE LLP | 2026-07-29 | Yes | No | No | 789019 | 911144442 | The API provides various data points about each entity, including their respective update timestamps, such as: - **Central Index Key (CIK)** - **Entity Name** - **Business and Mailing Address** - **State of Incorporation** - **Standard Industrial Classification (SIC)** - **Fiscal Year-End** - **Phone Number** - **IRS/EIN Number** - **Auditor Details**: Name, firm ID, and location - **Latest ICFR Auditor Attestation Date and Source Filing** - **Filer Category**: Large accelerated filer, non-accelerated filer, etc. - **Extended Categories**: Small business, emerging growth company, well-known seasoned issuer, etc. - **And more** Database Size: Over 890,000 EDGAR filing entities from 1994 to the present. Data Update Frequency: Updated in real-time as new filings are submitted to the SEC. Survivorship Bias-Free: Yes, the database includes all entities that have filed with the SEC since 1994, including entities that are no longer active or have ceased filing. ## API Endpoints EDGAR entities are searchable through two API endpoints: 1. **GET Endpoint** **URL**: `https://api.sec-api.io/edgar-entities?cik=` - Retrieves detailed information about an entity using its Central Index Key (CIK). - **Response**: A JSON object containing the entity's details. 2. **POST Endpoint** **URL**: `https://api.sec-api.io/edgar-entities` - Allows searching for entities based on various criteria, such as name, address, auditor details, and more. - **Payload**: A JSON object containing the search parameters. - **Response**: A JSON array of entities matching the search criteria. Both endpoints return the same data structure. The `GET` endpoint provides information about a single entity, while the `POST` endpoint supports more complex queries and returns information about multiple entities. ### Authentication To authenticate API requests, use the API key available in your [user profile](https://sec-api.io/signup/free). Utilize the API key in one of two ways. Choose the method that best fits your implementation: - **Authorization Header**: Set the API key as an `Authorization` header in the `GET` or `POST` request. For instance, before sending a `POST` request to `https://api.sec-api.io/edgar-entities`, ensure the header is set as follows: `Authorization: YOUR_API_KEY` - **Query Parameter**: Alternatively, append the API key directly to the URL as a query parameter. For example, when making `GET` requests, use the URL `https://api.sec-api.io/edgar-entities?cik=&token=YOUR_API_KEY` instead of the base API endpoint. ## Request Parameters ### GET Endpoint The `GET` endpoint `/edgar-entities?cik=` accepts a single query parameter: - **`cik`**: The Central Index Key (CIK) of the entity for which information is being requested. The CIK is a unique identifier assigned to each entity filing with the SEC EDGAR system. ### POST Endpoint The `POST` endpoint `/edgar-entities` accepts a JSON payload containing search parameters to filter and query EDGAR entities. The payload fields are described below: - **`query`** (string): A search query string to filter EDGAR filing entities by fields such as `cik`, `name`, `address`, `auditor`, or any other response field. The query is written in the Lucene syntax, for example `cik:1318605` to search by CIK or `formTypes.10-K:true AND shellCompany:true` to search for entities that have filed a 10-K filing and are shell companies. Supported features include: boolean operators (`AND`, `OR`,`NOT`), wildcards (`*`), nested queries (`()`), and range queries ( `[min TO max]`). - **`from`** (string|integer, optional): The starting index of the result set, used for pagination. Default: `0`. Maximum: `10000`. For example, `"from": 50` returns the second page of results, `"from": 100` retrieves the third page, and so on. - **`size`** (string|integer, optional): The number of entities to include in each response. Default: `50`. Maximum: `50`. - **`sort`** (array of objects, optional): Specifies the field and order for sorting results in the format `[{ "": ""}]`. The default order `[{ "cikUpdatedAt": "desc" }]` sorts by the `cikUpdatedAt` field in descending order. Each object in the array includes: - **``** (string): The field by which to sort. - **``** (string): Sorting order, either `asc` (ascending) or `desc` (descending). ### Request Examples **GET Request**: ``` GET https://api.sec-api.io/edgar-entities?cik=1318605 ``` **POST Request**: `POST` request to search for entities with the auditor "PwC" of firm ID "238", sorted by the latest ICFR audit date: ```json { "query": "latestIcfrAuditFiledAt:* AND auditorFirmId:238", "from": 0, "size": 50, "sort": [{"latestIcfrAuditFiledAtUpdatedAt":"desc"}] } ``` ## Response Format The EDGAR Entities API returns information about filer entities in JSON format. The response object includes the following fields: - `total` (object): An object with two fields:`value` (int) and `relation` (str). The`value` field contains the total number of entities that match the search criteria, while the `relation` field indicates the relationship between the total count and the returned entities. Possible values for `relation` include `eq` (equal) and`gte` (greater than or equal). - `data` (array of objects): An array of JSON objects, each representing an entity that matches the search criteria. Each object contains various fields with information about the entity, such as CIK, name, address, auditor details, and more: - `cik` (str): The Central Index Key (CIK) of the entity. Leading zeros are removed, and the CIK is formatted as a string, e.g., "1769624". - `name` (str): The name of the entity. - `businessAddress` (object): An object containing the business address of the entity, with fields such as `street1`,`street2`, `city`, `state`,`zip`, and `country`. - `mailingAddress` (object): An object containing the mailing address of the entity, with fields such as `street1`,`street2`, `city`, `state`,`zip`, and `country`. - `stateOfIncorporation` (str): The state of incorporation of the entity, e.g., "DE" for Delaware. - `phone` (str): The phone number of the entity. - `irsNo` (str): The Internal Revenue Service (IRS) tax identification number of the entity, e.g., "981742455". - `sic` (str): The Standard Industrial Classification (SIC) code of the entity, e.g., "3576" for Computer Communications Equipment. - `sicLabel` (str): The label corresponding to the SIC code, e.g., "Computer Communications Equipment". - `cfOffice` (str): The Central Filing Office of the entity, e.g., "06 Technology". - `fiscalYearEnd` (str): Month and day marking the end of the entity's fiscal year in `MMDD` format, e.g., "1231" for December 31. - `filerCategory` (str): The filer category of the entity. Possible values include "Large Accelerated Filer", "Accelerated Filer" and "Non-accelerated Filer". - `wellKnownSeasonedIssuer` (bool): `true` if the entity is a well-known seasoned issuer, as defined in Rule 405 of the Securities Act. `false` otherwise. - `voluntaryFiler` (bool): `true` if the entity is not required to file. `false` otherwise. - `smallBusiness` (bool): `true` if the company is a Smaller Reporting Company (SRC). - `emergingGrowthCompany` (bool): `true` if the entity is an emerging growth company as defined in the Jumpstart Our Business Startups (JOBS) Act. `false` otherwise. - `shellCompany` (bool): `true` if the entity is a shell company as defined in Rule 12b-2 of the Exchange Act.`false` otherwise. - `currentReportingStatus` (bool): `true` if the entity has (1) filed all reports required to be filed by Section 13 or 15(d) of the Securities Exchange Act of 1934 during the preceding 12 months (or for such shorter period that registrants were required to file such reports), and (2) have been subject to such filing requirements for the past 90 days. `false` otherwise. - `interactiveDataCurrent` (bool): `true` if the entity has submitted electronically every Interactive Data File required to be submitted pursuant to Rule 405 of Regulation S-T during the preceding 12 months (or for such shorter period that the registrant was required to submit such files). - `latestIcfrAuditFiledAt` (date): The date of the latest auditor attestation of the entity's internal control over financial reporting (ICFR). Format: `YYYY-MM-DDTHH:MM:SS-04:00`, eg`2024-09-25T16:21:22-04:00`. - `latestIcfrAuditSource` (str): The accession number of the filing that includes the latest ICFR auditor attestation. - `auditorName` (str): The name of the entity's auditor, e.g. "DELOITTE & TOUCHE LLP". - `auditorFirmId` (str): The firm ID of the entity's auditor, e.g. "34". - `auditorLocation` (str): The location of the entity's auditor, e.g. "Seattle, Washington". - `formTypes` (object): An object containing all form types filed by the entity since its registration with the SEC, with fields such as `{ "10-K": true, "10-Q": true, ... }`. Each field within a `data` object has a corresponding`UpdatedAt` field that indicates the timestamp of the last update to that specific field. For instance, `nameUpdatedAt` represents the timestamp of the most recent update to the entity's name. ### Response Examples #### `GET` Response Example Response example for the `GET` request to `/edgar-entities?cik=1318605`: GET Response Example ```json { "total": { "value": 1, "relation": "eq" }, "data": [ { "id": "1318605", "cik": "1318605", "cikUpdatedAt": "2005-02-23T11:38:36-05:00", "name": "Tesla, Inc.", "nameUpdatedAt": "2024-01-26T21:00:20-05:00", "businessAddress": { "street1": "3500 DEER CREEK RD", "street2": null, "city": "PALO ALTO", "state": "CA", "zip": "94304", "country": "" }, "businessAddressUpdatedAt": "2018-02-20T21:18:42-05:00", "mailingAddress": { "street1": "3500 DEER CREEK RD", "street2": null, "city": "PALO ALTO", "state": "CA", "zip": "94304", "country": "" }, "mailingAddressUpdatedAt": "2018-02-20T21:18:42-05:00", "irsNo": "912197729", "irsNoUpdatedAt": "2009-04-09T15:30:06-04:00", "stateOfIncorporation": "DE", "stateOfIncorporationUpdatedAt": "2009-04-09T15:30:06-04:00", "phone": "650-681-5000", "phoneUpdatedAt": "2010-10-29T12:35:46-04:00", "sic": "3711", "sicUpdatedAt": "2010-01-29T16:16:56-05:00", "sicLabel": "3711 Motor Vehicles & Passenger Car Bodies", "sicLabelUpdatedAt": "2024-01-02T16:29:17-05:00", "cfOffice": "04 Manufacturing", "cfOfficeUpdatedAt": "2024-04-01T18:57:33-04:00", "currentReportingStatus": true, "currentReportingStatusUpdatedAt": "2024-10-23T20:42:47-04:00", "interactiveDataCurrent": true, "interactiveDataCurrentUpdatedAt": "2024-10-23T20:42:47-04:00", "wellKnownSeasonedIssuer": false, "wellKnownSeasonedIssuerUpdatedAt": "2024-04-02T16:47:22-04:00", "voluntaryFiler": false, "voluntaryFilerUpdatedAt": "2011-08-12T16:41:17-04:00", "filerCategory": "Large Accelerated Filer", "filerCategoryUpdatedAt": "2012-02-27T17:17:24-05:00", "smallBusiness": false, "smallBusinessUpdatedAt": "2011-08-12T16:41:17-04:00", "emergingGrowthCompany": false, "emergingGrowthCompanyUpdatedAt": "2011-08-12T16:41:17-04:00", "shellCompany": false, "shellCompanyUpdatedAt": "2011-08-12T16:41:17-04:00", "fiscalYearEnd": "1231", "fiscalYearEndUpdatedAt": "2012-06-08T16:25:18-04:00", "latestIcfrAuditFiledAt": "2024-01-26T21:00:20-05:00", "latestIcfrAuditFiledAtUpdatedAt": "2024-01-26T21:00:20-05:00", "latestIcfrAuditSource": "0001628280-24-002390", "latestIcfrAuditSourceUpdatedAt": "2024-01-26T21:00:20-05:00", "auditorName": "PricewaterhouseCoopers LLP", "auditorNameUpdatedAt": "2022-02-04T20:11:27-05:00", "auditorFirmId": "238", "auditorFirmIdUpdatedAt": "2022-02-04T20:11:27-05:00", "auditorLocation": "San Jose, California", "auditorLocationUpdatedAt": "2022-02-04T20:11:27-05:00", "formTypes": { "3": true, "4": true, "5": true, "144": true, "425": true, "10-K": true, "10-K/A": true, "10-Q": true, "3/A": true, "4/A": true, "424B3": true, "424B4": true, "424B5": true, "5/A": true, "8-A12B": true, "8-K": true, "8-K/A": true, "ARS": true, "CERTNAS": true, "CORRESP": true, "CT ORDER": true, "D": true, "DEF 14A": true, "DEFA14A": true, "EFFECT": true, "FWP": true, "LETTER": true, "NO ACT": true, "NT 10-K": true, "POS AM": true, "PRE 14A": true, "PX14A6G": true, "PX14A6N": true, "REDACTED EXHIBIT": true, "REGDEX": true, "REGDEX/A": true, "S-1": true, "S-1/A": true, "S-3ASR": true, "S-4": true, "S-4/A": true, "S-8": true, "S-8 POS": true, "SC 13G": true, "SC 13G/A": true, "SC TO-T": true, "SC TO-T/A": true, "SD": true }, "formTypesUpdatedAt": "2024-11-15T10:54:38-05:00" } ] } ``` #### `POST` Response Example Response example for the `POST` request to search EDGAR registrants that have filed an ICFR audit and have PwC as their auditor, sorted by the latest ICFR audit date: ```json { "query": "latestIcfrAuditFiledAt:* AND auditorFirmId:238", "from": 0, "size": 50, "sort": [{"latestIcfrAuditFiledAtUpdatedAt":"desc"}] } ``` **Response**: POST Response Example ```json { "total": { "value": 569, "relation": "eq" }, "data": [ { "id": "1314727", "cik": "1314727", "cikUpdatedAt": "2005-01-25T15:04:37-05:00", "name": "Sonos Inc", "nameUpdatedAt": "2023-04-04T18:29:22-04:00", "businessAddress": { "street1": "301 COROMAR DRIVE", "street2": null, "city": "SANTA BARBARA", "state": "CA", "zip": "93117", "country": "" }, "businessAddressUpdatedAt": "2024-05-06T12:47:24-04:00", "mailingAddress": { "street1": "301 COROMAR DRIVE", "street2": null, "city": "SANTA BARBARA", "state": "CA", "zip": "93117", "country": "" }, "mailingAddressUpdatedAt": "2024-05-06T12:47:24-04:00", "irsNo": "030479476", "irsNoUpdatedAt": "2010-03-22T14:48:01-04:00", "stateOfIncorporation": "DE", "stateOfIncorporationUpdatedAt": "2010-03-22T14:48:01-04:00", "phone": "805-965-3001", "phoneUpdatedAt": "2010-03-22T14:48:01-04:00", "sic": "3651", "sicUpdatedAt": "2018-01-18T11:13:55-05:00", "sicLabel": "3651 Household Audio & Video Equipment", "sicLabelUpdatedAt": "2018-01-18T11:13:55-05:00", "cfOffice": "04 Manufacturing", "cfOfficeUpdatedAt": "2024-04-04T11:47:45-04:00", "currentReportingStatus": true, "currentReportingStatusUpdatedAt": "2024-11-15T16:49:12-05:00", "interactiveDataCurrent": true, "interactiveDataCurrentUpdatedAt": "2024-11-15T16:49:12-05:00", "wellKnownSeasonedIssuer": false, "wellKnownSeasonedIssuerUpdatedAt": "2018-09-11T14:14:55-04:00", "voluntaryFiler": false, "voluntaryFilerUpdatedAt": "2018-09-11T14:14:55-04:00", "filerCategory": "Large Accelerated Filer", "filerCategoryUpdatedAt": "2019-11-25T17:51:18-05:00", "smallBusiness": false, "smallBusinessUpdatedAt": "2018-09-11T14:14:55-04:00", "emergingGrowthCompany": false, "emergingGrowthCompanyUpdatedAt": "2018-09-11T14:14:55-04:00", "shellCompany": false, "shellCompanyUpdatedAt": "2018-09-11T14:14:55-04:00", "latestIcfrAuditFiledAt": "2024-11-15T16:49:12-05:00", "latestIcfrAuditFiledAtUpdatedAt": "2024-11-15T16:49:12-05:00", "latestIcfrAuditSource": "0001314727-24-000026", "latestIcfrAuditSourceUpdatedAt": "2024-11-15T16:49:12-05:00", "auditorName": "PricewaterhouseCoopers LLP", "auditorNameUpdatedAt": "2022-11-23T16:02:39-05:00", "auditorFirmId": "238", "auditorFirmIdUpdatedAt": "2022-11-23T16:02:39-05:00", "auditorLocation": "Los Angeles, California", "auditorLocationUpdatedAt": "2022-11-23T16:02:39-05:00", "formTypes": { "3": true, "4": true, "144": true, "10-K": true, "10-Q": true, "144/A": true, "3/A": true, "424B4": true, "8-A12B": true, "8-K": true, "8-K/A": true, "CERT": true, "CORRESP": true, "CT ORDER": true, "D": true, "DEF 14A": true, "DEFA14A": true, "DRS": true, "DRS/A": true, "DRSLTR": true, "EFFECT": true, "LETTER": true, "REGDEX": true, "S-1": true, "S-1/A": true, "S-8": true, "SC 13G": true, "SC 13G/A": true, "SD": true }, "formTypesUpdatedAt": "2024-11-15T16:49:12-05:00" } // ... ] } ``` ## FAQ Common questions about querying the EDGAR Entities Database API, the response shape, and the bulk archives. ### How do I look up the full profile of a single company that files with the SEC when I only know its CIK number? To retrieve the full EDGAR profile for one entity by its CIK, use the GET form of the `/edgar-entities` endpoint and supply the CIK as the lookup key (`cik`). For example, calling `/edgar-entities?cik=1318605` returns Tesla's record with leading zeros stripped from the CIK. The response is a JSON object with a `total` object and a `data` array containing a single entity. That entity carries the company's name (`name`), business and mailing addresses (`businessAddress`, `mailingAddress`), state of incorporation (`stateOfIncorporation`), SIC code and label (`sic`, `sicLabel`), filer category (`filerCategory`), auditor details (`auditorName`, `auditorFirmId`, `auditorLocation`), and the full list of form types ever filed (`formTypes`). Each business attribute is paired with a corresponding `UpdatedAt` timestamp so you can see when each piece of information last changed. ```bash https://api.sec-api.io/edgar-entities?cik=1318605&token=YOUR_API_KEY ``` ### How do I find a company's SEC profile by its legal name when I don't know its CIK? Use the POST form of the `/edgar-entities` endpoint and filter on the entity name field (`name`). For an exact match, the value of `name` should equal the legal name as it appears in EDGAR, for example `Tesla, Inc.` or `Sonos Inc`. Wildcards are supported, so a partial match such as `Tesla*` will catch variations and abbreviations. The response includes a `total.value` count of matches and a `data` array. Each match contains the entity's CIK (`cik`), which you can then reuse against the GET endpoint or in further queries. Because name changes are tracked separately, the `nameUpdatedAt` timestamp on each record tells you when the company last updated its registered name. ```json { "query": "name:\"Tesla, Inc.\"", "from": 0, "size": 50, "sort": [{"cikUpdatedAt":"desc"}] } ``` ### How do I retrieve all companies that have the same auditor by firm ID? To list every entity audited by a particular PCAOB-registered firm, use the POST `/edgar-entities` endpoint and filter on the auditor firm identifier (`auditorFirmId`). For example, the value `238` corresponds to PricewaterhouseCoopers LLP, so setting `auditorFirmId` to `238` returns every filer whose latest ICFR auditor attestation lists that firm. The `total.value` field in the response tells you how many entities the firm audits across EDGAR, and each entry in `data` includes the audit firm name (`auditorName`), the office location (`auditorLocation`), and the accession number of the source filing (`latestIcfrAuditSource`). Sorting by `latestIcfrAuditFiledAtUpdatedAt` in descending order surfaces the most recently confirmed engagements first. ```json { "query": "auditorFirmId:238", "from": 0, "size": 50, "sort": [{"latestIcfrAuditFiledAtUpdatedAt":"desc"}] } ``` ### How do I list every public company audited by a specific accounting firm such as Deloitte or PwC? Use the POST `/edgar-entities` endpoint and filter on the auditor name field (`auditorName`). The value should match how the firm appears in the auditor attestation, such as `PricewaterhouseCoopers LLP` or `Deloitte & Touche LLP`. Filtering by the exact string ensures you do not pick up unrelated affiliates. The `total.value` in the response tells you the count of audited entities, and each `data` entry carries the firm identifier (`auditorFirmId`) and the auditor office location (`auditorLocation`). If you prefer a more stable identifier that does not depend on firm-name spelling, filter on `auditorFirmId` instead — for example, `238` for PwC. ```json { "query": "auditorName:\"PricewaterhouseCoopers LLP\"", "from": 0, "size": 50 } ``` ### How do I find all SEC filers headquartered in a particular U.S. state? To locate every filer with a business address in a given U.S. state, use the POST `/edgar-entities` endpoint and filter on the state code on the business address object (`businessAddress.state`). The value should be the two-letter postal abbreviation, such as `CA` for California or `NY` for New York. The `total.value` field shows how many entities match, and each `data` entry includes the full business address (`businessAddress.street1`, `businessAddress.city`, `businessAddress.zip`) along with the corresponding mailing address (`mailingAddress`). Note that the business address reflects the operating headquarters reported to EDGAR, which may differ from the state of incorporation (`stateOfIncorporation`). ```json { "query": "businessAddress.state:CA", "from": 0, "size": 50 } ``` ### How do I find SEC-registered entities located in a specific city such as San Francisco? Use the POST `/edgar-entities` endpoint and filter on the city portion of the business address (`businessAddress.city`). City names in EDGAR are stored in uppercase, so the value should look like `SAN FRANCISCO` or `NEW YORK`. The `data` array returned contains the entity name (`name`), the full street address (`businessAddress.street1`, `businessAddress.street2`), state (`businessAddress.state`), and ZIP code (`businessAddress.zip`). If you need to disambiguate cities with the same name in different states — for example, Springfield — combine the city filter with `businessAddress.state` set to the appropriate two-letter postal code. ```json { "query": "businessAddress.city:\"SAN FRANCISCO\"", "from": 0, "size": 50 } ``` ### How do I search for companies incorporated in a specific state like Delaware? To find companies that are legally incorporated in a particular jurisdiction, use the POST `/edgar-entities` endpoint and filter on the state of incorporation field (`stateOfIncorporation`). The value should be the two-letter postal code such as `DE` for Delaware, `NV` for Nevada, or `MD` for Maryland. This is distinct from the headquarters location: many companies are incorporated in Delaware but operate elsewhere, so the response will surface entities whose `businessAddress.state` differs from `stateOfIncorporation`. The `total.value` field in the response gives you the count of incorporated entities, and the `stateOfIncorporationUpdatedAt` timestamp on each record indicates when that fact was last refreshed in EDGAR. ```json { "query": "stateOfIncorporation:DE", "from": 0, "size": 50 } ``` ### How do I find all companies operating within a specific industry? Use the POST `/edgar-entities` endpoint and filter on the Standard Industrial Classification code (`sic`). The value is the four-digit SIC code that EDGAR assigns to each filer, for example `3711` for Motor Vehicles & Passenger Car Bodies or `7372` for Prepackaged Software. The response also includes the human-readable label (`sicLabel`) on each entity, which combines the code and description, for example `3711 Motor Vehicles & Passenger Car Bodies`. If you do not know the precise code, you can do a wildcard search on `sicLabel` to find candidates and then narrow down to the exact `sic` value once you have it. ```json { "query": "sic:7372", "from": 0, "size": 50 } ``` ### How do I retrieve every entity within a broader industry category such as Manufacturing or Technology? To group filers by the SEC Division of Corporation Finance's broader industry office instead of by individual SIC code, use the POST `/edgar-entities` endpoint and filter on the Central Filing Office (`cfOffice`). The value should be the office label as EDGAR records it, such as `04 Manufacturing`, `06 Technology`, or `Office of Trade & Services`. The `cfOffice` field clusters dozens of related SIC codes under one umbrella, which makes it well-suited for industry-level analysis where the narrow four-digit `sic` filter would be too restrictive. Each match returned still carries the underlying `sic` and `sicLabel`, so you can drill down to a specific sub-industry after the broader filter. ```json { "query": "cfOffice:\"06 Technology\"", "from": 0, "size": 50 } ``` ### How do I identify which companies are flagged as shell companies in SEC records? Use the POST `/edgar-entities` endpoint and filter on the shell company flag (`shellCompany`). The value of `shellCompany` should be `true` to return only entities that are designated as shell companies under Rule 12b-2 of the Exchange Act. Each matching record in the `data` array includes the entity name (`name`), CIK (`cik`), state of incorporation (`stateOfIncorporation`), and the timestamp of the last shell-company status change (`shellCompanyUpdatedAt`). Combining this filter with `formTypes.10-K` set to `true` further narrows the result to shell companies that have filed annual reports, which is often the starting point for due-diligence on reverse-merger candidates. ```json { "query": "shellCompany:true", "from": 0, "size": 50 } ``` ### How do I find every entity that qualifies as an emerging growth company under the JOBS Act? To list entities flagged as emerging growth companies under the Jumpstart Our Business Startups Act, use the POST `/edgar-entities` endpoint and filter on the emerging growth flag (`emergingGrowthCompany`). The value of `emergingGrowthCompany` should be `true`. The response returns the count in `total.value` along with each entity's identifying details. Because EGC status is time-bounded — companies lose it five years after IPO or once they cross certain revenue or float thresholds — the `emergingGrowthCompanyUpdatedAt` timestamp tells you when the designation was last confirmed in EDGAR, which is useful for filtering out stale flags. ```json { "query": "emergingGrowthCompany:true", "from": 0, "size": 50 } ``` ### How do I find smaller reporting companies registered with the SEC? Use the POST `/edgar-entities` endpoint and filter on the smaller reporting company flag (`smallBusiness`). The value of `smallBusiness` should be `true` to return only entities that meet the Smaller Reporting Company (SRC) thresholds. Each record contains the entity name (`name`), CIK (`cik`), filer category (`filerCategory`), and the timestamp of the last SRC status update (`smallBusinessUpdatedAt`). Because SRC and accelerated filer status interact, combining `smallBusiness` set to `true` with `filerCategory` set to `Non-accelerated Filer` narrows the result to the more common small-cap profile. ```json { "query": "smallBusiness:true", "from": 0, "size": 50 } ``` ### How do I find well-known seasoned issuers as defined in Rule 405? To list well-known seasoned issuers (WKSIs) as defined in Rule 405 of the Securities Act, use the POST `/edgar-entities` endpoint and filter on the WKSI flag (`wellKnownSeasonedIssuer`). The value of `wellKnownSeasonedIssuer` should be `true`. The `data` array returns each WKSI's CIK (`cik`), name (`name`), filer category (`filerCategory`), and the timestamp of the most recent WKSI confirmation (`wellKnownSeasonedIssuerUpdatedAt`). Because WKSI status is reassessed annually based on public float and reporting history, the update timestamp lets you focus on issuers whose status is freshly confirmed rather than legacy assignments. ```json { "query": "wellKnownSeasonedIssuer:true", "from": 0, "size": 50 } ``` ### How do I filter for entities by their filer category such as Large Accelerated Filer vs Non-accelerated Filer? Use the POST `/edgar-entities` endpoint and filter on the filer category field (`filerCategory`). The value should be the exact category label EDGAR uses, such as `Large Accelerated Filer`, `Accelerated Filer`, or `Non-accelerated Filer`. Filer category drives many SEC requirements — accelerated filing deadlines, internal-control attestation obligations, and disclosure scope — so this is often combined with other filters. For example, restricting to `Large Accelerated Filer` and pairing it with `wellKnownSeasonedIssuer` set to `true` isolates the most established public companies. Each record's `filerCategoryUpdatedAt` timestamp shows when EDGAR last reclassified the entity. ```json { "query": "filerCategory:\"Large Accelerated Filer\"", "from": 0, "size": 50 } ``` ### How do I find companies that are currently up to date with their SEC reporting obligations? To find filers in good standing with their Exchange Act reporting obligations, use the POST `/edgar-entities` endpoint and filter on the current reporting status flag (`currentReportingStatus`). The value of `currentReportingStatus` should be `true`, which indicates the entity has filed all required reports under Section 13 or 15(d) over the preceding twelve months and has been subject to those requirements for at least 90 days. A related quality signal is interactive data filing compliance (`interactiveDataCurrent`), which should be `true` for entities that have submitted all required XBRL files. Combining both flags returns the cleanest set of filers for analytical work. The `currentReportingStatusUpdatedAt` timestamp tells you when EDGAR last reassessed the status. ```json { "query": "currentReportingStatus:true", "from": 0, "size": 50 } ``` ### How do I find companies that have ever filed an annual report? Use the POST `/edgar-entities` endpoint and filter on the form-types map for annual reports (`formTypes.10-K`). The value of `formTypes.10-K` should be `true` to return only entities that have submitted at least one Form 10-K since 1994. The `formTypes` object is a flat boolean map of every form type the entity has ever filed, so it captures historical filings even if the company is no longer active. This makes it well-suited for survivorship-bias-free studies. The amendment counterpart `formTypes.10-K/A` records 10-K/A filings separately, so requiring it as well narrows the result to companies that have filed at least one amended annual report. ```json { "query": "formTypes.10-K:true", "from": 0, "size": 50 } ``` ### How do I find every entity that has filed a particular form, such as Form D or Form 4? Use the POST `/edgar-entities` endpoint and filter on the relevant key inside the form-types map (`formTypes`). For Form D, the value of `formTypes.D` should be `true`; for Form 4, the value of `formTypes.4` should be `true`. The same pattern works for any other form: `formTypes.8-K`, `formTypes.S-1`, `formTypes.SC 13G`, and so on. The `formTypes` field is a boolean map of every form type the entity has ever submitted, so the filter returns entities that have filed the form at least once, not necessarily recently. Each `data` entry still carries `formTypesUpdatedAt`, which is the timestamp when the form-types map for that entity last changed — a useful proxy for filing activity. ```json { "query": "formTypes.D:true", "from": 0, "size": 50 } ``` ### How do I find all Business Development Companies? A Business Development Company (BDC) is a closed-end fund that has formally elected to be regulated as a BDC under §54(a) of the Investment Company Act of 1940 by filing Form N-54A (Notification of Election by Business Development Company). Because only BDCs ever file this notification, the cleanest filter at the POST `/edgar-entities` endpoint is `formTypes.N-54A` set to `true`. Each result carries the entity's CIK (`cik`), name (`name`), business address (`businessAddress`), and the full form-types map. Note that entities that later revoked their BDC election with Form N-54C are still returned, since the form-types map is a cumulative history — combine with `formTypes.N-54C:false` if you want only currently electing BDCs. ```json { "query": "formTypes.N-54A:true", "from": 0, "size": 50 } ``` ### How do I locate entities that have filed an amendment to a specific filing type? Use the POST `/edgar-entities` endpoint and filter on the amended form key inside the form-types map (`formTypes`). Amendment forms use the original form code followed by `/A`, so for an amended annual report the value of `formTypes.10-K/A` should be `true`, and for an amended Form 4 the value of `formTypes.4/A` should be `true`. Because the `formTypes` map records each variant separately, you can combine the base form and its amendment in one query — for example requiring both `formTypes.10-K` and `formTypes.10-K/A` to be `true` — to find companies that have filed and later amended an annual report. This pattern is the standard way to surface restatement candidates. ```json { "query": "formTypes.10-K/A:true", "from": 0, "size": 50 } ``` ### How do I list companies whose most recent internal control audit was filed within a specific date range? Use the POST `/edgar-entities` endpoint and filter on the latest ICFR audit filing date (`latestIcfrAuditFiledAt`). The value of `latestIcfrAuditFiledAt` should fall between the start and end of the window you want, for example between `2024-01-01` and `2024-12-31` to surface companies whose most recent ICFR attestation was filed during calendar year 2024. The `total.value` field tells you how many filers had a fresh ICFR audit in that window, and sorting by `latestIcfrAuditFiledAtUpdatedAt` in descending order returns the most recently confirmed audits first. Pair the date filter with `auditorFirmId` to scope the result to a particular accounting firm, or with `filerCategory` set to `Large Accelerated Filer` to focus on issuers required to provide auditor attestation. ```json { "query": "latestIcfrAuditFiledAt:[2024-01-01 TO 2024-12-31]", "from": 0, "size": 50, "sort": [{"latestIcfrAuditFiledAtUpdatedAt":"desc"}] } ``` ### How do I find filers whose fiscal year ends on a particular calendar date such as June 30? Use the POST `/edgar-entities` endpoint and filter on the fiscal year end field (`fiscalYearEnd`). The value is a four-character string in `MMDD` format with no separator, so June 30 is `0630`, December 31 is `1231`, and September 30 is `0930`. This is useful for aligning peer-group analyses to a common reporting cadence — for example, retail companies commonly use January fiscal year ends, while many financial firms and universities use June. The `fiscalYearEndUpdatedAt` timestamp on each record indicates when the fiscal-year-end was last changed in EDGAR, which can help identify companies that have realigned their reporting calendar. ```json { "query": "fiscalYearEnd:0630", "from": 0, "size": 50 } ``` ### How do I look up a company by its IRS/EIN tax identification number? Use the POST `/edgar-entities` endpoint and filter on the IRS tax identification field (`irsNo`). The value should be the nine-digit EIN as a string without the hyphen, for example `912197729` for Tesla, Inc. or `030479476` for Sonos Inc. The response returns the matching entity's name (`name`), CIK (`cik`), and full address details (`businessAddress`, `mailingAddress`). Because EDGAR allows the EIN to be populated with placeholder zeros for some entities — particularly newly registered partnerships and special-purpose vehicles — a value of `000000000` is not a real EIN and should be treated as missing. The `irsNoUpdatedAt` timestamp tells you when the EIN was last reported. ```json { "query": "irsNo:912197729", "from": 0, "size": 50 } ``` ### How do I retrieve a list of insider individuals who have only ever filed insider-ownership reports? Use the POST `/edgar-entities` endpoint and filter on the form-types map (`formTypes`) so that at least one of the insider-ownership forms is `true` — `formTypes.3`, `formTypes.4`, or `formTypes.5` — while the keys for operating-company forms such as `formTypes.10-K`, `formTypes.10-Q`, `formTypes.8-K`, and `formTypes.S-1` are all absent or `false`. This isolates filers whose entire EDGAR history consists of Section 16 ownership reports, which is characteristic of individual insiders rather than corporate issuers. The matching `data` entries typically carry a personal name in `name` (for example a last-name-first format like `Kiernan Michael`) and a mailing address that often appears as `C/O` the employer. Because EDGAR does not have an explicit person-versus-company flag, this form-types pattern is the practical proxy. The `formTypesUpdatedAt` timestamp surfaces the most recently active insiders. ```json { "query": "(formTypes.3:true OR formTypes.4:true OR formTypes.5:true) AND NOT formTypes.10-K:true AND NOT formTypes.10-Q:true AND NOT formTypes.8-K:true AND NOT formTypes.S-1:true", "from": 0, "size": 50, "sort": [{"formTypesUpdatedAt":"desc"}] } ``` ### How do I find entities whose corporate name has been updated since a certain date? Use the POST `/edgar-entities` endpoint and filter on the name-update timestamp (`nameUpdatedAt`). The value of `nameUpdatedAt` should be greater than or equal to the cutoff date — for example, anything on or after `2024-01-01` — to return entities whose registered name has changed within that window. The `data` entries returned include the current name (`name`), the prior CIK assignment date (`cikUpdatedAt`), and the form-types map (`formTypes`), which together let you distinguish a routine rebranding from a reverse-merger shell that has taken on a new identity. Sorting by `nameUpdatedAt` in descending order surfaces the most recent renames first. ```json { "query": "nameUpdatedAt:[2024-01-01 TO *]", "from": 0, "size": 50, "sort": [{"nameUpdatedAt":"desc"}] } ``` ### How do I page through more than 50 search results when many entities match my criteria? The POST `/edgar-entities` endpoint caps each response at 50 entities through the `size` parameter, whose maximum is also `50`. To page through a larger result set, increment the `from` parameter by the page size on each subsequent call — `from` of `0` returns the first page, `from` of `50` returns the second, `from` of `100` returns the third, and so on, up to a maximum offset of `10000`. The `total.value` field in every response tells you how many entities match the query in total, so you know when to stop paging. To keep paging stable across calls, always supply an explicit `sort` order — for instance sorting by `cikUpdatedAt` in descending order — so the underlying ordering does not shift between pages. ```json { "query": "stateOfIncorporation:DE", "from": 50, "size": 50, "sort": [{"cikUpdatedAt":"desc"}] } ``` ### How do I sort search results by when an entity's record was most recently updated? Use the POST `/edgar-entities` endpoint and supply the `sort` parameter pointing at one of the per-field update timestamps. For overall record freshness, sort by the CIK update timestamp (`cikUpdatedAt`) in descending order; for the most recent corporate-name changes, sort by `nameUpdatedAt` in descending order. Because every business attribute carries its own `UpdatedAt` companion, you can pick the timestamp that matches the dimension you care about — for example `latestIcfrAuditFiledAtUpdatedAt` to surface recently audited filers, or `formTypesUpdatedAt` to surface entities with the most recent filing activity. The default sort order if none is specified is `cikUpdatedAt` in descending order. ```json { "query": "currentReportingStatus:true", "from": 0, "size": 50, "sort": [{"cikUpdatedAt":"desc"}] } ``` ### How do I combine multiple filters in a single search, such as Delaware-incorporated tech companies that filed a 10-K? The POST `/edgar-entities` endpoint accepts compound queries in the `query` field, so several filters can be combined in one request. For Delaware-incorporated software companies that have filed an annual report, the value of `stateOfIncorporation` should be `DE`, the value of `sic` should be `7372` for Prepackaged Software, and the value of `formTypes.10-K` should be `true`, all joined together so every condition must hold. The `total.value` field shows the count of entities meeting all conditions simultaneously. Parentheses let you group alternatives — for instance, allowing either `7372` or `7370` as the SIC code while still requiring the other two conditions — and negation lets you exclude unwanted categories, such as filtering out entities whose `shellCompany` is `true` to focus on operating businesses. ```json { "query": "stateOfIncorporation:DE AND sic:7372 AND formTypes.10-K:true", "from": 0, "size": 50 } ``` ### How do I count how many SEC filers exist in a given industry without retrieving them all? Use the POST `/edgar-entities` endpoint with the relevant industry filter — for example `sic` set to `7372` or `cfOffice` set to `06 Technology` — and set `size` to `1` so only one record is returned. The count you need is in the `total.value` field of the response, which reflects how many entities match the query regardless of how many were returned in `data`. The accompanying `total.relation` field is either `eq` when the count is exact or `gte` when it is a lower bound, which matters for very large result sets. This pattern is the standard way to do cardinality-only analysis without paying the bandwidth cost of fetching every record. ```json { "query": "sic:7372", "from": 0, "size": 1 } ``` ### How do I find companies whose auditor is located in a specific city, to spot potential auditor-concentration risk? Use the POST `/edgar-entities` endpoint and filter on the auditor office location field (`auditorLocation`). The value should be the city-and-state string as EDGAR records it on the auditor attestation, for example `San Jose, California` or `Los Angeles, California`. The `total.value` field tells you how many issuers rely on auditors based in that city, and pairing the filter with `auditorFirmId` narrows further to a specific firm's office — useful when one regional office serves a heavy concentration of clients in a single industry. To assess concentration risk across an industry, combine `auditorLocation` with `sic` or `cfOffice` so the result reflects only the relevant peer group. ```json { "query": "auditorLocation:\"San Jose, California\"", "from": 0, "size": 50 } ``` ### How do I detect companies that recently switched auditors so I can flag potential audit-quality concerns? To surface entities whose auditor assignment has changed recently, use the POST `/edgar-entities` endpoint and lean on the auditor-name update timestamp (`auditorNameUpdatedAt`). Sorting by `auditorNameUpdatedAt` in descending order brings the freshest auditor changes to the top of the result set, and filtering so that the value of `auditorNameUpdatedAt` is on or after a chosen cutoff date — for example, anything from `2024-01-01` onwards — narrows the result to recent switches. Each `data` entry returned carries the current auditor name (`auditorName`), the firm identifier (`auditorFirmId`), the auditor office location (`auditorLocation`), and the accession number of the source attestation (`latestIcfrAuditSource`). The companion timestamps `auditorFirmIdUpdatedAt` and `auditorLocationUpdatedAt` change in lockstep with the name when the engagement actually moves to a different firm, which helps you separate genuine auditor changes from routine re-confirmations of the same engagement. Combining the date filter with `filerCategory` set to `Large Accelerated Filer` focuses attention on the larger issuers where auditor turnover is most material. ```json { "query": "auditorNameUpdatedAt:[2024-01-01 TO *]", "from": 0, "size": 50, "sort": [{"auditorNameUpdatedAt":"desc"}] } ``` ### How do I find companies that file with the SEC voluntarily even though they aren't required to? To list entities that continue to submit Exchange Act reports even though they are not required to do so, use the POST `/edgar-entities` endpoint and filter on the voluntary filer flag (`voluntaryFiler`). The value of `voluntaryFiler` should be `true`, which on EDGAR indicates the entity is not subject to the reporting requirements of Section 13 or 15(d) but is filing anyway. Each `data` entry returns the entity name (`name`), CIK (`cik`), filer category (`filerCategory`), and the timestamp when the voluntary status was last confirmed (`voluntaryFilerUpdatedAt`). Pairing the filter with `currentReportingStatus` set to `true` further restricts the result to voluntary filers that are also up to date on the reports they choose to file, which is a useful subset for investor-relations and credit-analysis work. ```json { "query": "voluntaryFiler:true", "from": 0, "size": 50 } ```