Reading the Launch Library API for Rocket Launch Schedules Without a Key

The Space Devs run Launch Library, a REST API covering orbital and suborbital launches worldwide, past and upcoming. No key, no signup, and a forward schedule that currently runs to 369 launches. If you need a dated calendar of something genuinely interesting, this is one of the easiest open APIs to consume.

The Endpoints

Base URL carries the version in the path:

https://ll.thespacedevs.com/2.3.0/

The three that matter:

launches/upcoming/     everything scheduled ahead
launches/previous/     everything flown
launches/              both
events/upcoming/       spacewalks, dockings, test fires

A minimal call:

https://ll.thespacedevs.com/2.3.0/launches/upcoming/?limit=12

That returns immediately with no headers set.

Use mode to Control Payload Size

This is the parameter that decides whether the API is pleasant or painful.

The default response is deeply nested. A single launch carries the full rocket configuration, the provider agency with its founding year and description, the pad with coordinates and a map image, the mission text, programme links, and several image URLs. Twelve launches in default mode is a large document.

?mode=list      minimal: name, net, status, id
?mode=normal    the default
?mode=detailed  everything, plus extra relations

Build a calendar view against mode=list, then fetch mode=detailed for the single launch a user clicks. Pulling detailed data for a whole page and rendering three fields from it is the usual waste here.

Filtering by Date

Django-style lookups on net, the “no earlier than” timestamp:

?net__gte=2026-10-01T00:00:00Z
?net__lte=2026-11-01T00:00:00Z

Combine them for a month window. Other useful filters:

?search=MMX                       free text across names and missions
?launch_service_provider__name=SpaceX
?status=1                         "Go for Launch"
?hide_recent_previous=true

Pagination Is Standard DRF

The response wraps results:

{
  "count": 369,
  "next": "https://ll.thespacedevs.com/2.3.0/launches/upcoming/?limit=12&offset=12",
  "previous": null,
  "results": [ ... ]
}

count is the total matching your filter, not the page size, and next is a complete URL. Follow it rather than building offsets yourself:

import requests

def all_launches(url):
    out = []
    while url:
        data = requests.get(url, timeout=30).json()
        out.extend(data["results"])
        url = data["next"]
    return out

Put a page cap on that loop before pointing it at launches/ with no filter, since the historical record runs to many thousands of entries.

The Field You Must Not Treat as a Date

net is “no earlier than,” and it is a planning value rather than a commitment. Read it together with status.abbrev, which takes values including Go, TBC and TBD.

In live data right now, a Falcon 9 carrying USSF-385 sits at 2026-09-26T11:56:00Z with status Go. A Starship flight nine days later reads 2026-09-28T12:15:00Z with status TBC. An Ariane 64 in October gives only 2026-10-07 with no time at all and status TBD.

Those are three different kinds of claim sharing one field. Render a TBD entry as a precise timestamp and your calendar will state that a rocket launches at midnight, because a date-only value parses to 00:00:00. Check whether the source string contains a time component before formatting it, and surface the status alongside every date you display.

Launches also slip constantly. Anything cached for longer than a few hours will be wrong, which is a point in favour of a scheduled rebuild or a short-lived edge cache rather than a build-time fetch you refresh weekly.

Rate Limits

Anonymous access is throttled and the ceiling is not published in the endpoint index. There is an api-throttle/ endpoint that reports your current standing, and the project offers higher tiers for accounts.

For a site rebuilding a few times a day this is a non-issue. For anything polling in a loop, check your throttle state before assuming you have room.

Why It Is Worth Building On

Dated, forward-looking, globally scoped, and updated by people who follow this closely. Very few open APIs give you a reliable calendar of future events with this much structure attached, and none of the alternatives skip the API key.

Related