Changelog
Back to All

Advanced Endpoints Open to Retail, CIK Lookup on Historical Float & a Sunset Date for Historical Tickers

27 days ago by Denys Malykhin

Covers changes since the September 12 changelog (September 13 to September 19, 2026).


Nothing breaks, but two things to check

  • GET /endpoints no longer prefixes deprecated labels. On September 12 we told you Historical Tickers would appear as DEPRECATED Historical Tickers in the label field. That prefix is gone; the label is plain again and deprecation is now reported as data. If you matched on the label, switch to the new deprecated field. See Historical Tickers.
  • /v1/historical-float-pro validation messages changed now that ticker is no longer the only identifier. If you match on the exact text of the 422, see Historical Float.

Offerings and Dilution Data "Funds & Underwriters" are now available on Retail plans

GET /v1/offerings-advanced and GET /v1/dilution-data-advanced were Enterprise-only. They are now available on every paid plan, Retail and above. Trial and Free keys continue to receive 403 endpoint_not_allowed. Both endpoints now appear in GET /endpoints for Retail keys. If your organization runs on a custom per-key endpoint allowlist, nothing changes for you; contact us to have the advanced endpoints added.

Request parameters and response shapes are exactly as before. Offerings Advanced adds bank and investors to each offering. Dilution Data Advanced adds owners, bank and pp_clause to each warrant and convertible, and both dilution endpoints carry floor_price.

Pricing. Both are priced at a premium multiple of their base endpoints: Offerings Advanced at 8x /v1/offerings, Dilution Data Advanced at 5x /v1/dilution-data. GET /v1/pricing reports the current per-GB rate and /estimate prices them accordingly.

Retail company cap: 75 distinct companies per rolling 24 hours. To keep the advanced data from being copied wholesale, non-Enterprise organizations may receive advanced data on at most 75 distinct companies in any rolling 24-hour window. The pool is shared across both advanced endpoints and every API key in your organization. This is separate from the per-minute request limit and from the trial ticker cap.

  • A company counts once it appears in a successful response. Companies are keyed by CIK, so a ticker change does not consume a second slot. A company stays counted until 24 hours after the last time you received it. There is no midnight reset.
  • Repeat queries for a company already in your active window, including further pages of its history, are not counted again. Normal usage charges still apply.
  • Empty responses, errors and rejected pages add nothing.
  • Searches without a ticker, by bank, investors, owner or a date range, count every company on the returned page. Use limit to bound how many slots such a query can consume.
  • Enterprise plans have no company cap.

A page that would push you past the cap is rejected in full: 429, error.code of advanced_company_limit, no data returned, nothing charged. The response tells you where you stand:

{
  "status": "error",
  "error": {
    "code": "advanced_company_limit",
    "message": "Advanced endpoints are limited to 75 distinct companies per rolling 24 hours per organization. Companies already in your active window remain accessible; contact [email protected] for a higher allowance.",
    "details": {
      "endpoint": "offerings-advanced",
      "limit": 75,
      "window_hours": 24,
      "active_companies": 72,
      "remaining_slots": 3,
      "companies_required": 5,
      "retry_after_seconds": 5400
    }
  },
  "request_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab"
}

retry_after_seconds, also sent as the Retry-After header, is when enough slots free up if you make no further advanced requests. It is null, and the header is omitted, when the page alone exceeds the cap. In that case narrow the query or lower limit. Companies already in your window remain queryable while you wait. If the cap check itself is temporarily unavailable, the request fails with the existing 503 service_unavailable and Retry-After: 5, safe to retry.

/v1/historical-float-pro: look up by CIK

New optional cik parameter, an alternative to ticker. Supply either; at least one is required. Use it when you hold SEC identifiers rather than symbols, or when a company has changed ticker: the CIK stays constant through symbol changes, so a CIK lookup returns the full float history without depending on the ticker-alias fallbacks.

  • Accepts one CIK or a comma-separated list, up to 100.
  • Leading zeros are optional. cik=1682149 and cik=0001682149 return the same rows.
  • Whitespace inside a token is stripped. Invalid tokens (anything other than one to ten digits) are dropped from a mixed list, the same rule that applies to ticker lists. You get a 422 only when every token is invalid: Invalid CIK(s): ... CIKs must contain only digits (1-10 characters).
  • If you pass both ticker and cik, rows must match both.
  • latest_data=true works with cik exactly as it does with ticker.
  • Ticker-only requests are unchanged.

Validation messages. A request with neither identifier now returns 422 with At least one of 'ticker' or 'cik' is required. Previously the message was 'ticker' parameter is required. The latest_data restriction now reads When latest_data=True, only 'ticker' and 'cik' parameters are allowed (no other filtering parameters).

Trial keys. CIKs count toward the trial cap of 50 unique tickers per endpoint per day. A company looked up once by ticker and once by CIK uses two slots.

Historical Tickers: sunset date set, deprecation headers added

On September 12 we deprecated GET /v1/historical-tickers and said we were not announcing a sunset date. We now are: the endpoint will be retired after 30 September 2027. Until then nothing about it changes. Same URL, same request, same response shape, same 404 on an unmatched ticker. Its documentation page keeps the title "DEPRECATED Historical Tickers". New integrations should use Ticker Changes.

Every response from a deprecated endpoint now carries three standard headers, on success, error and cached responses alike, so you can detect the schedule without reading docs:

Deprecation: @1788998400
Sunset: Thu, 30 Sep 2027 23:59:59 GMT
Link: <https://eapi.askedgar.io/v1/ticker-changes>; rel="successor-version", <https://eapi.askedgar.io/v1/docs>; rel="deprecation"; type="text/html"

Deprecation is an RFC 9745 structured-field date, @ plus Unix seconds, marking when the deprecation was announced (10 September 2026). Sunset is an RFC 8594 HTTP-date marking when the endpoint may go away. Link names the replacement endpoint and the documentation, as one comma-separated header. Parsing note: the two date headers use different formats by design.

GET /endpoints now reports deprecation as data. Each entry gains two fields: deprecated (boolean) and sunset (an ISO date, or null). The label field is a plain slug-derived name again, so Historical Tickers reads Historical Tickers, not DEPRECATED Historical Tickers. Filter on deprecated rather than matching labels.

The OpenAPI document marks the operation deprecated: true and carries an x-sunset: "2027-09-30" extension, so generated clients and tooling that read the spec pick the schedule up automatically.