01 / AVIATIONOpen docs ↗
OpenSky Network
Live and historical aircraft state data for position, altitude and movement projects.
- Access
- REST API · account/rate limits apply
- Build idea
- Aircraft tracker
APIs & DATA · INFORMATION INTO OBJECTSGive your build
Give your build
a view of the world.
Weather on your desk. Arrivals by the door. A signal when something changes. Find the data, make it reliable, then give it a physical form.
12 source guides8 subjects to explore4 stages to a display
Concept display showing sample data.
What can you build from this data?
An API gives your project information. Start with an outcome, then choose a source.
WEATHER & ENVIRONMENT
See changing conditions
A desk display for forecasts or air-quality readings.
Explore weather data →TRANSPORT
Know when to leave
Arrivals and service updates in a purpose-built enclosure.
Explore transport data →ENERGY
Make a change visible
Turn carbon-intensity data into a display or indicator.
Explore energy data →Build ideas. Source coverage, hardware and implementation need checking for your project.
THE SOURCE DIRECTORY
Useful data for physical builds
Check coverage, update frequency and access before committing to a source.
12 sources
Clear filters02 / WEATHEROpen docs ↗
Open-Meteo
Forecast, historical and environmental weather data with useful no-key routes.
- Access
- No-key non-commercial access · usage limits apply
- Build idea
- Weather display
- Check first
- The free hosted endpoint is for non-commercial use. Check the service plan separately from the weather-data licence before selling a connected product. Source details ↗
03 / SPACEOpen docs ↗
NASA Open APIs
Astronomy, imagery and public space datasets including APOD and near-earth-object data.
- Access
- API key for standard use
- Build idea
- Space event display
04 / SPACEOpen docs ↗
JPL Solar System Dynamics
Authoritative small-body, orbit and solar-system data suitable for astronomy indicators.
- Access
- Public APIs
- Build idea
- Near-earth object indicator
05 / TRANSPORTOpen docs ↗
TfL Unified API
London lines, arrivals, disruptions and transport-network data.
- Access
- Anonymous + registered routes
- Build idea
- Departure board
06 / ENVIRONMENTOpen docs ↗
OpenAQ
Global air-quality observations for particulate and pollutant-driven physical indicators.
- Access
- API key
- Build idea
- Air-quality signal
07 / SPORTOpen docs ↗
football-data.org
Competitions, teams, matches and tables for scoreboards, lamps and match-day objects.
- Access
- API token · competition and plan limits
- Build idea
- Fixtures and score display
- Check first
- The free plan has delayed scores. Confirm competition coverage and a live-score plan before designing goal alerts. Source details ↗
08 / CIVICOpen docs ↗
GOV.UK Bank Holidays
Official UK bank-holiday dates by nation in a simple public JSON feed.
- Access
- Public JSON
- Build idea
- Calendar indicator
09 / ENVIRONMENTOpen docs ↗
Environment Agency Flood Monitoring
Near-real-time flood warnings, river levels, flows and monitoring-station data for England.
- Access
- Open data · no registration
- Build idea
- River or flood warning object
10 / CIVICOpen docs ↗
Police API
Crime and outcome records for England, Wales and Northern Ireland, plus neighbourhood policing information.
- Access
- Public JSON API · monthly crime releases
- Build idea
- Monthly local-area report
- Check first
- Crime locations are approximate and anonymised. Use the reporting month and coverage to explain the data; this is not a live incident feed or an immediate safety assessment. Source details ↗
11 / TRANSPORTOpen docs ↗
Open Charge Map
Community-maintained EV charging locations, operators and connection metadata.
- Access
- API key / registered developer
- Build idea
- Nearby charger indicator
12 / ENERGYOpen docs ↗
NESO Carbon Intensity API
Official Great Britain current, forecast and regional electricity carbon-intensity data.
- Access
- Public API · CC BY 4.0
- Build idea
- Low-carbon power signal
No matching sources. Try another search or clear the filters.
Choose a source your build can actually use.
The directory links to services. It does not connect them for you or supply an API key.
What is an API, and what do I need?
An API lets your program request information in a defined format. The endpoint is the address you request; the response contains fields such as a value, its unit and a timestamp. Start with the provider's example response before choosing a screen or writing firmware.
You need internet access for a live online source, code that understands the response, and an output such as a display or printer. The browser exercises use sample data; completing them does not connect a live service.
Will the data cover my place and purpose?
Check location, update frequency, units, time zone, missing readings and permitted use. A national feed may not cover your station or street. A forecast is not an observation. Decide how old a reading may be before your device labels it stale.
Open the provider's terms for attribution and redistribution requirements. Free access does not mean unlimited use.
Where should a private API key live?
A key identifies a caller and may allow billable requests. Follow the provider's instructions: a private server key should not be published in browser code or an open repository. A server-side service can keep that key while returning only the data your device needs.
Device firmware is not a guaranteed secret store. For a first experiment, a suitable no-key source can avoid this extra setup.
Why does a request work elsewhere but fail in a browser?
Browsers enforce cross-origin rules called CORS. The API must permit your web page to read its response. This differs from a request made by a server or microcontroller; it does not remove authentication or usage limits.
What happens when the service slows down or fails?
Use a request timeout and a bounded retry policy. HTTP 429 means too many requests; respect the provider's limit and any Retry-After instruction. Keep the last reading with its timestamp, or show unavailable if you have no valid reading. Never silently turn a missing value into zero.
How do I get from the exercise to a device?
First parse a saved response. Then make one permitted live request and check the units and timestamp. Add stale-data and failure behaviour before connecting the output. Finally test power loss, network loss and restart behaviour on the actual device.
Choose the physical output around the information: a screen for changing detail, a printed brief for a snapshot, or an indicator for one clearly defined state.
Follow the four-stage route →A reading is just the beginning.
Work through four stages. Each adds something your finished display needs.
01
Read one value
Parse a response. Check its type, units and range.
A usable reading →02Handle stale data
Track when it arrived. Show when it is out of date.
A freshness check →03Recover from failure
Handle missing values and failed requests without crashing.
A resilient adapter →04Plan the physical build
Choose an output and follow the source-guided printer handoff.
A hardware handoff →
TAKE IT INTO A BUILD
Information you can hold.
The Morning Thermal Printer is an assessed project that turns weather and calendar information into a printed daily briefing. Explore its requirements, then plan your own source and output.
Illustration: display concept, not a photograph of the printer.EXPAND WHAT YOU CAN BUILD
Go beyond fetching a reading.
Choose where information comes from, where decisions happen and what the physical output should do when the world is imperfect.
01Cloud data, local sensors or both?Does this need an internet service, a reading from your own space, or a combination?
Starting pointDefine the location, units, update interval and acceptable delay.
Try itUse sample inputs to compare a remote feed with a local observation. Decide which one answers the actual question and what to show when either is missing.
Make something you can reviewA source map and freshness rules for each input.
Judge the resultA forecast and a sensor measure different things. Check placement, calibration, timestamps and units before combining readings.
Explore a sensor calibration example →02Choose where the logic runsShould the device decide locally, use a home server, or call a cloud service?
Starting pointIdentify what must keep working without internet access.
Try itSketch device → data → decision → output. Compare a local rule with a server-assisted version. Prototype with a display or log and test disconnection before allowing actions.
Make something you can reviewAn architecture sketch, dependency list and offline behaviour.
Judge the resultConsider memory, latency, maintenance, network access and keys. HTTP requests, MQTT messaging and device APIs need different setup; choose for the job.
Explore ESPHome’s device API →03Make an output that earns its placeWould a light, sound, printed briefing or physical control work better than another dashboard?
Starting pointKnow who uses the information and when they need it.
Try itMock two outputs from the same saved data. Ask someone to act on them. Add delayed, contradictory and unavailable cases; use a log before triggering a mechanism.
Make something you can reviewAn output comparison and a clear rule for when to notify, update or do nothing.
Judge the resultMeasure comprehension and unwanted interruptions. If AI interprets messy input, validate its structured result before it reaches device logic.
Explore a physical briefing project →Find new developments and people building things.
Explore these sources, then bring back an idea or a documented result. A source listing is not a CAIBI assessment of everything it publishes.
- Seeed Studio ↗Hardware developments
Explore boards, sensors and edge-AI hardware, then follow the product documentation for compatibility.
Seeed Studio on X ↗ - Edge Impulse ↗AI inside a device
Explore training and deploying models on devices. AI inference is a different role from AI helping design the build.
Edge Impulse on X ↗
Source links checked 16 September 2026.
Found a build, useful source or something we missed? Send it to CAIBI →