Skill

Generate Production-Ready FastAPI Endpoints

A skill generating type-safe FastAPI CRUD endpoints with Pydantic models, JWT auth, file uploads, and background tasks.

Works with fastapipydanticsqlalchemy

79
Spark score
out of 100
Updated 7 months ago
Version 1.0.0
Models

Add to Favorites

Why it matters

Automate the creation of robust, production-ready FastAPI API endpoints. This asset ensures your APIs are built with type safety, proper error handling, security, and clear documentation from the start.

Outcomes

What it gets done

01

Generate Pydantic models for request/response validation.

02

Implement CRUD operations with appropriate HTTP status codes.

03

Integrate authentication and authorization patterns.

04

Set up comprehensive error handling middleware.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-fastapi-endpoint-generator | bash

Overview

FastAPI Endpoint Generator

This skill generates FastAPI CRUD endpoints with Pydantic request/response models, HTTPBearer JWT authentication, global exception handlers, and advanced patterns for file uploads and background tasks. Use it when a FastAPI endpoint needs typed validation, structured error responses, and OpenAPI documentation built in from the start.

What it does

This skill generates robust, production-ready FastAPI endpoints with proper validation, error handling, documentation, and security. Core principles: type safety first via Pydantic models for every request/response, correct HTTP status codes per scenario, comprehensive error handling with meaningful messages, clear OpenAPI documentation with examples, authentication/authorization patterns where needed, and attention to async/await and database connection handling for performance.

When to use - and when NOT to

Use it when a FastAPI endpoint needs typed request/response validation, structured error responses, and OpenAPI documentation built in from the start, not just a bare @app.get returning a dict.

class UserCreate(BaseModel):
    email: EmailStr
    name: str = Field(..., min_length=1, max_length=100)

@app.post("/users/", response_model=UserResponse, status_code=status.HTTP_201_CREATED)
async def create_user(user_data: UserCreate, db: Session = Depends(get_db)):
    existing_user = db.query(User).filter(User.email == user_data.email).first()
    if existing_user:
        raise HTTPException(status_code=409, detail="User with this email already exists")
    db_user = User(**user_data.dict())
    db.add(db_user)
    db.commit()
    return db_user

Inputs and outputs

CRUD patterns cover create (with a duplicate-email 409 check and rollback on failure), read-by-ID (404 on missing) and paginated list (skip/limit query params with validation bounds), and update with an authorization check comparing the current user to the resource owner or admin flag. Authentication uses HTTPBearer security with a get_current_user dependency that decodes and validates a JWT, raising 401 on failure; authorization then compares that resolved user against the request. Global exception handlers catch ValueError (mapped to a structured 400) and any uncaught Exception (mapped to a generic 500), both returning a consistent {"detail": ..., "error_code": ...} shape. Advanced patterns include a file-upload endpoint validating content type and a 5MB size limit, and a background-task endpoint that queues an email notification via BackgroundTasks and returns immediately. Configuration is centralized in a Pydantic Settings class reading from a .env file (database URL, secret key, JWT algorithm, token expiry).

Who it's for

Python developers building FastAPI services who want typed, documented, production-ready CRUD endpoints - with authentication, file uploads, and background tasks - generated consistently rather than hand-written per route. Best practices tie it together: use dependency injection for database sessions and shared logic, validate early with Pydantic Field validators, return the status code that matches the operation (201 for creation, 204 for deletion), include response examples in the OpenAPI docs, group endpoints with OpenAPI tags so the generated documentation stays organized as the API grows, and add a health-check endpoint so the service can be monitored the same way any other production endpoint would be.

FAQ

Common questions

Discussion

Questions & comments ยท 0

Sign In Sign in to leave a comment.