From Notebook to Network:
Building a House Price Prediction API

Problem

A machine learning model that lives in a Jupyter notebook is not a product — it is a local artifact that only the person who trained it can use. Sharing predictions with another team, integrating the model into an application, or running it in production all require the same thing: an API. The challenge is that building a robust service around a model involves concerns that notebooks never teach: input validation, startup performance, error handling, endpoint design, and schema enforcement. Without those properties, a model that performs well in isolation fails the moment it encounters unexpected inputs or concurrent requests in a real environment. The gap between "I trained a model" and "I deployed a model" is exactly the gap between a data science project and a data science product.

Solution

This project wrapped a pre-trained Random Forest regressor in a FastAPI service that validates all 13 house features at the schema layer, loads the model once at startup to avoid per-request overhead, and exposes three REST endpoints: health check, model metadata, and prediction. FastAPI's automatic OpenAPI documentation made the service self-describing from day one without additional work. Pydantic models enforced strict type checking at the boundary, catching malformed inputs before they reached the model and returning structured error responses to callers. The service went through three rounds of reviewer feedback across the sprint, with each iteration tightening the production correctness of the design — from how health check responses were typed to ensuring consistent output schemas on every prediction. The end result was a service that any downstream application could call with confidence, treating the model as infrastructure rather than a notebook artifact.

Skills Acquired

• Python — the implementation language for both the trained model and the FastAPI service layer that wraps it.
• FastAPI — the web framework used to build and expose the REST API. FastAPI's declarative routing, native Pydantic integration, and automatic OpenAPI documentation generation make it the modern standard for Python model-serving applications — and a frequent topic in ML engineering interviews.
• Pydantic — the data validation library that enforces input and output schemas at the API boundary. Every prediction request was validated against a typed PredictionRequest model, and every response returned a typed PredictionResponse — preventing malformed data from reaching the model or being surfaced to callers.
• scikit-learn — the machine learning framework that produced the trained Random Forest regressor. In this project, scikit-learn's predict() method was called inside the FastAPI endpoint handler, taking Pydantic-validated inputs and returning numeric predictions.
• joblib — used to serialize and deserialize the trained model artifact. Loading a joblib-serialized model once at application startup is a standard production pattern — avoiding the latency spike that would occur if the model had to be deserialized on every incoming request.
• NumPy — used to convert Pydantic-validated input data into the array format that scikit-learn's predict() method expects, bridging the schema-validated request object and the model's numerical interface.
• REST API — the interface design pattern applied throughout the service. Three HTTP endpoints were designed following REST conventions, making the service callable from any language, tool, or application that can send HTTP requests.

Those tools together answer a question worth sitting with: what does it actually take to move a model out of a notebook and into something that works?

Deep Dive

Training a machine learning model is one skill. Making it useful — wrapping it in an API, validating inputs before they ever reach the model, documenting endpoints so someone else can actually call it — that's a different skill entirely. And until now, I hadn't fully learned it.

This project changed that. I built a production-ready FastAPI service that loads a trained Random Forest regressor at startup, exposes three REST endpoints, validates all 13 house features through Pydantic schemas, and returns structured JSON predictions with model metadata. By the time the last line was reviewed, I had gone from writing Python scripts to thinking in services.

Why This Project?

This was Sprint 11 of my TripleTen AI and Machine Learning Bootcamp, focused on model deployment and API development. The assignment: wrap a pre-trained Random Forest regressor in a FastAPI application that could accept house feature data, validate it, run inference, and return a structured prediction response �� all with proper error handling and health monitoring.

I chose to treat this as a real engineering exercise, not a box to check. Every decision — from loading the model once at startup instead of on every request, to returning Pydantic models from check_health() instead of raw dictionaries — was made with production correctness in mind. The reviewer feedback across three iterations confirmed exactly where those habits were forming.

What You'll Learn from This

• How FastAPI startup events prevent models from loading on every request — and why that matters at scale
• Why Pydantic schemas do more than validate data: they self-document your API and catch contract violations before they reach inference
• The difference between returning a raw dictionary and returning a typed response model — and why it matters for schema consistency
• How to maintain feature ordering between training and inference using metadata['features']
• Why 503 Service Unavailable is the semantically correct status code when a model isn't loaded
• How structured reviewer feedback accelerates growth — and how to incorporate it without losing the thread

Key Takeaways

• Model loaded once at startup via @app.on_event("startup") — not on each request, not lazily on first hit
• Three endpoints — /health, /model/info, /predict — each with typed Pydantic response models
• All 13 features validated by HousePredictionRequest with Field() constraints before reaching inference
• Feature order preserved using metadata['features'] — the same order used during training, guaranteed consistent
• Iterative reviewer feedback drove three rounds of refinement, each one tightening schema consistency and eliminating unnecessary data handling

The Service

The application predicts US apartment prices based on 13 property features: listing images, bedrooms, bathrooms, area, latitude, longitude, and seven binary amenity flags (garden, garage, new construction, pool, terrace, air conditioning, parking). The pre-trained Random Forest regressor and its metadata are loaded from disk; the API wraps them in a clean, documented HTTP interface.

How I Built It

from pydantic import BaseModel, Field
from datetime import datetime

class HousePredictionRequest(BaseModel):
    total_images:      int   = Field(..., ge=0,    le=50)
    beds:              int   = Field(..., ge=0,    le=10)
    baths:             float = Field(..., ge=0,    le=10)
    area:              float = Field(..., gt=0,    le=10000)
    latitude:          float = Field(..., ge=-90,  le=90)
    longitude:         float = Field(..., ge=-180, le=180)
    garden:            int   = Field(..., ge=0,    le=1)
    garage:            int   = Field(..., ge=0,    le=1)
    new_construction:  int   = Field(..., ge=0,    le=1)
    pool:              int   = Field(..., ge=0,    le=1)
    terrace:           int   = Field(..., ge=0,    le=1)
    air_conditioning:  int   = Field(..., ge=0,    le=1)
    parking:           int   = Field(..., ge=0,    le=1)

class PredictionResponse(BaseModel):
    predicted_price: float = Field(description="Predicted price in USD")
    currency:        str   = Field(default="USD")   # default avoids repetition
    model_version:   str   = Field(description="Model version string")

class HealthCheckResponse(BaseModel):
    status:          str  = Field(description="healthy or unhealthy")
    model_loaded:    bool
    message:         str

import joblib, numpy as np, json

model    = None
metadata = None

def load_model_and_metadata():
    global model, metadata
    try:
        model    = joblib.load('model.pkl')
        with open('model_metadata.json') as f:
            metadata = json.load(f)
        return True
    except Exception as e:
        print(f"Error loading model: {e}")
        return False

def make_prediction(house_features):
    # Extract features in training order — ordering matters for the model
    feature_values = [house_features[f] for f in metadata['features']]
    X = np.array(feature_values).reshape(1, 13)
    return round(float(model.predict(X)[0]), 2)

def check_health():
    model_ok    = model    is not None
    metadata_ok = metadata is not None
    return HealthCheckResponse(
        status         = "healthy" if model_ok and metadata_ok else "unhealthy",
        model_loaded   = model_ok,
        metadata_loaded= metadata_ok,
        message        = "Both model and metadata are loaded"
                         if model_ok and metadata_ok
                         else "Model or metadata not loaded"
    )

from fastapi import FastAPI, HTTPException

app = FastAPI(title="House Price Prediction API", version="1.0.0")

# Load once at startup — never on each request
@app.on_event("startup")
async def startup_event():
    success = load_model_and_metadata()
    if not success:
        print("WARNING: Failed to load model at startup")

@app.post("/predict", response_model=PredictionResponse)
async def predict(request: HousePredictionRequest):
    try:
        features_dict   = request.dict()
        predicted_price = make_prediction(features_dict)
        model_version   = get_model_info()["version"]  # extract only what's needed
        return PredictionResponse(
            predicted_price=predicted_price,
            currency="USD",
            model_version=model_version
        )
    except ValueError as e:
        raise HTTPException(status_code=503, detail=str(e))
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"Prediction failed: {e}")

Three Rounds of Reviewer Feedback

Each file went through two rounds of review — an initial submission and a revision pass. The feedback wasn't about correctness (the logic worked from the start). It was about consistency, clarity, and production-readiness.

Conclusion & Reflections

The biggest shift in this project wasn't technical — it was conceptual. I stopped thinking in terms of notebooks and started thinking in terms of services. A notebook has no contract. A service does. Every input must be validated. Every output must conform to a schema. Every failure mode must return a meaningful response. Getting that right required understanding why each piece existed, not just how to make it run.

FastAPI made a lot of this natural. The framework enforces schema thinking — you have to define your request and response models to get the routing to work at all. Pydantic handles validation automatically. The startup event pattern keeps expensive operations out of the hot path. These aren't just conveniences; they're guardrails that push you toward building correctly by default.

If I deployed this service today, a client could send a POST to /predict with 13 house features and get back a JSON object with the predicted price, the currency, and the model version — all validated, all typed, all documented in the auto-generated Swagger UI. That's a real thing. That's not a notebook anymore.