How many times have you had a messy Jupyter Notebook filled with copy-pasted code just to re-use some data wrangling logic? Whether you do it for passion or for work, if you code a lot, then you’ve probably answered something like “way too many”. You’re not alone. Maybe you tried to share data with colleagues or plugging your latest ML model into a slick dashboard, but sending CSVs or rebuilding the dashboard from scratch doesn’t feel correct. Here’s today’s fix (and topic): build yourself a personal API.In this post, I’ll show you how to set up a lightweight, powerful FastAPI service to expose your datasets or models and finally give your data projects the modularity they deserve. Whether you’re a solo Data Science enthusiast, a student with side projects, or a seasoned ML engineer, this is for you. And no, I’m not being paid to promote this service. It’d be good, but the reality is far from that. I just happen to enjoy using it and I thought it was worth being shared. Let’s review today’s table of contents: What is a personal API? (And why should you care?) Some use cases Setting it up with Fastapi Conclusion What Is a Personal API? (And Why Should You Care?) 99% of people reading this will already be familiar with the API concept. But for that 1%, here’s a brief intro that will be complemented with code in the next sections: An API (Application Programming Interface) is a set of rules and tools that allows different software applications to communicate with each other. It defines what you can ask a program to do, such as “give me the weather forecast” or “send a message.” And that program handles the request behind the scenes and returns the result. So, what is a personal API? It’s essentially a small web service that exposes your data or logic in a structured, reusable way. Think of it like a mini app that responds to HTTP requests with JSON versions of your data. Why would that be a good idea? In my opinion, it has different advantages: As already mentioned, reusability. We can use it from our Notebooks, dashboards or scripts without having to rewrite the same code several times. Collaboration: your teammates can easily access your data through the API endpoints without needing to duplicate your code or download the same datasets in their machines. Portability: You can deploy it anywhere—locally, on the cloud, in a container, or even on a Raspberry Pi. Testing: Need to test a new feature or model update? Push it to your API and instantly test across all clients (notebooks, apps, dashboards). Encapsulation and Versioning: You can version your logic (v1, v2, etc.) and separate raw data from processed logic cleanly. That’s a huge plus for maintainability. And FastAPI is perfect for this. But let’s see some real use cases where anyone like you and me would benefit from a personal API. Some Use Cases Whether you’re a data scientist, analyst, ML engineer, or just building cool stuff on weekends, a personal API can become your secret productivity weapon. Here are three examples: Model-as-a-service (MASS): train an ML model locally and expose it to your public through an endpoint like /predict. And options from here are endless: rapid prototyping, integrating it on a frontend… Dashboard-ready data: Serve preprocessed, clean, and filtered datasets to BI tools or custom dashboards. You can centralize logic in your API, so the dashboard stays lightweight and doesn’t re-implement filtering or aggregation. Reusable data access layer: When working on a project that contains multiple Notebooks, has it ever happened to you that the first cells on all of them contain always the same code? Well, what if you centralized all that code into your API and got it done from a single request? Yes, you could modularize it as well and call a function to do the same, but creating the API allows you to go one step further, being able to use it easily from anywhere (not just locally). I hope you get the point. Options are endless, just like its usefulness. But let’s get to the interesting part: building the API. Setting it up with FastAPI As always, start by setting up the environment with your favorite env tool (venv, pipenv…). Then, install fastapi and uvicorn with pip install fastapi uvicorn. Let’s understand what they do: FastAPI[1]: it’s the library that will allow us to develop the API, essentially. Uvicorn[2]: it’s what will allow us to run the web server. Once installed, we only need one file. For simplicity, we’ll call it app.py. Let’s now put some context into what we’ll do: Imagine we’re building a smart irrigation system for our vegetable garden at home. The irrigation system is quite simple: we have a moisture sensor that reads the soil moisture with certain frequency, and we want to activate the system when it’s below 30%. Of course we want to automate it locally, so when it hits the threshold it starts dropping water. But we’re also interested in being able to access the system remotely, maybe reading the current value or even triggering the water pump if we want to. That’s when the personal API can come in handy. Here’s the basic code that will allow us to do just that (note that I’m using another library, duckdb[3], because that’s where I would store the data — but you could just use sqlite3, pandas, or whatever you like): import datetime from fastapi import FastAPI, Query import duckdb app = FastAPI() conn = duckdb.connect("moisture_data.db") @app.get("/last_moisture") def get_last_moisture(): query = "SELECT * FROM moisture_reads ORDER BY day DESC, time DESC LIMIT 1" return conn.execute(query).df().to_dict(orient="records") @app.get("/moisture_reads/{day}") def get_moisture_reads(day: datetime.date, time: datetime.time = Query(None)): query = "SELECT * FROM moisture_reads WHERE day = ?" args = [day] if time: query += " AND time = ?" args.append(time) return conn.execute(query, args).df().to_dict(orient="records") @app.get("/trigger_irrigation") def trigger_irrigation(): # This is a placeholder for the actual irrigation trigger logic # In a real-world scenario, you would integrate with your irrigation system here return {"message": "Irrigation triggered"} Reading vertically, this code separates three main blocks: Imports Setting up the app object and the DB connection Creating the API endpoints 1 and 2 are pretty straightforward, so we’ll focus on the third one. What I did here was create 3 endpoints with their own functions: /last_moisture shows the last sensor value (the most recent one). /moisture_reads/{day} is useful to see the sensor reads from a single day. For example, if I wanted to compare moisture levels in winter with the ones in summer, I would check what’s in /moisture_reads/2024-01-01 and observe the differences with /moisture_reads/2024-08-01.But I’ve also made it able to read GET parameters if I’m interested in checking a specific time. For example: /moisture_reads/2024-01-01?time=10:00 /trigger_irrigation would do what the name suggests. So we’re only missing one part, starting the server. See how simple it is to run it locally: uvicorn app:app --reload Now I could visit: http://localhost:8000/last_moisture to see my last moisture http://localhost:8000/moisture_reads/2024-01-01 to see the moisture levels of January 1st, 2024. http://localhost:8000/trigger_irrigation to start pumping water. But it doesn’t end here. FastAPI provides another endpoint which is found in http://localhost:8000/docs that shows autogenerated interactive documentation for our API. In our case: It’s extremely useful when the API is collaborative, because we don’t need to check the code to be able to see all the endpoints we have access to! And with just a few lines of code, very few in fact, we’ve been able to build our personal API. It can obviously get a lot more complicated (and probably should) but that wasn’t today’s purpose. Conclusion With just a few lines of Python and the power of FastAPI, you’ve now seen how easy it is to expose your data or logic through a personal API. Whether you’re building a smart irrigation system, exposing a machine learning model, or just tired of rewriting the same wrangling logic across notebooks—this approach brings modularity, collaboration, and scalability to your projects. And this is just the beginning. You could: Add authentication and versioning Deploy to the cloud or a Raspberry Pi Chain it to a frontend or a Telegram bot Turn your portfolio into a living, breathing project hub If you’ve ever wanted your data work to feel like a real product—this is your gateway. Let me know if you build something cool with it. Or even better, send me the URL to your /predict, /last_moisture, or whatever API you’ve made. I’d love to see what you come up with. Resources [1] Ramírez, S. (2018). FastAPI (Version 0.109.2) [Computer software]. https://fastapi.tiangolo.com [2] Encode. (2018). Uvicorn (Version 0.27.0) [Computer software]. https://www.uvicorn.org [3] Mühleisen, H., Raasveldt, M., & DuckDB Contributors. (2019). DuckDB (Version 0.10.2) [Computer software]. https://duckdb.org The post Building a Personal API for Your Data Projects with FastAPI appeared first on Towards Data Science.