API Migration Guide

Migrate from the legacy KLISS API (v1 through v13 at /li/api/vN/) to the new API at /api/v1/. If you're seeing a Deprecation header on your API responses, you're in the right place.

Timeline

The five things that changed

1. Getting an API key

The new API works without a key (throttled to 30 requests/minute). An API key raises this to 300 requests/minute.

1. Visit /api/request-key/.
2. Fill out: name, email, organization, and how you plan to use the API.
3. Wait for approval — typically one business day.
4. You'll receive the key by email with usage instructions.

Include it as an HTTP header on every request:

Authorization: Api-Key <your-key>

cURL example:

curl -H 'Authorization: Api-Key abc123...' \
     https://kslegislature.gov/api/v1/bill_status/HB2001/

Python example:

import requests

headers = {'Authorization': 'Api-Key abc123...'}
r = requests.get('https://kslegislature.gov/api/v1/bill_status/HB2001/',
                 headers=headers)
data = r.json()

2. The easy path: bill_status drop-in

If your code uses bill_status/ (any version), the new API has a purpose-built replacement that matches the v13 response shape. For many consumers this is a two-line change:

- url = 'http://kslegislature.org/li/api/v13/rev-1/bill_status/HB2001/'
- r = requests.get(url)
+ url = 'https://kslegislature.gov/api/v1/bill_status/HB2001/'
+ r = requests.get(url, headers={'Authorization': 'Api-Key <key>'})

The response carries the same fields: BILLNO, SHORTTITLE, LONGTITLE, SPONSOR_NAMES, STATUS, HISTORY (with action_code, chamber, journal_page_number, occurred_datetime, status, committee_names, amendment_report), and versions.

3. Endpoint mapping (all resources)

4. Response format changes

Legacy v1 through v4

Responses were bare JSON arrays or objects. The new API always wraps content with metadata:

{
  "count": 1480,
  "next": "https://kslegislature.gov/api/v1/measures/?limit=100&offset=100",
  "previous": null,
  "results": [ ... ]
}

Field name changes (v4 → v5+)

v5 of the legacy API renamed several keys. If your code still uses v1–v4 field names, update to the v5+ spelling (preserved in the new API):

5. Pagination

The legacy API used a next link that was often set to "disabled". The new API uses standard limit/offset pagination:

GET /api/v1/measures/?limit=100&offset=0

Loop until next is null to fetch all records:

def fetch_all(url, headers):
    results = []
    while url:
        r = requests.get(url, headers=headers)
        data = r.json()
        results.extend(data['results'])
        url = data['next']
    return results

6. Biennium scoping

Legacy URLs encoded the biennium in the path (/li_2022/). The new API uses a query parameter that defaults to the current active biennium:

/api/v1/bill_status/                      # current biennium
/api/v1/bill_status/?biennium=b2023_24   # historical biennium
/api/v1/measures/?biennium=b2023_24      # works on every endpoint

7. RSS & Atom feeds

RSS feeds moved from /li/feeds/rss/ to /feeds/rss/. No authentication required.

Atom equivalents: replace /rss/ with /atom/ in any URL above. See /feeds/rsshelp/ for a full list with subscribe links.

8. Errors you may encounter

9. Deprecation headers on legacy responses

Every legacy API response now carries these headers:

Deprecation: true
Sunset: Sat, 01 Aug 2026 00:00:00 GMT
Link: <https://kslegislature.gov/api/docs/>; rel="successor-version",
      <https://kslegislature.gov/api/docs/migration/>; rel="help"

If your HTTP client can log response headers, you can confirm you're still hitting the legacy API.

10. Getting help

If your use case isn't covered or you hit a bug during migration:

• Email [email protected]
• Reference your API key label (first 12 characters) when reporting issues
• Include the exact URL you called and the response body you received