Overview
I built the platform’s REST API layer — the CRUD endpoints the web and mobile apps of a fiber-optic ISP call to read and write their data. They live across several FastAPI services running serverlessly on AWS Lambda behind API Gateway, backed by Amazon DocumentDB, all following the same layered, validated, auth-guarded pattern so the surface stays consistent and safe as it grows.
The problem
A CRUD endpoint on its own is routine — but a platform with a web portal, a mobile app and internal tools needs a lot of them, and the real risk isn’t any single endpoint, it’s drift: validation, auth, errors and pagination each solved a little differently until the API becomes inconsistent and unsafe to consume. The work here was making every resource validated, authenticated, authorized, and shaped the same way — a surface that stays coherent, secure (IDOR-safe, idempotent), and cheap to extend as new resources are added.
What I built
I built on the platform’s shared serverless infrastructure — API Gateway, the Cognito authorizer, and the container / CDK / CI-CD scaffolding, set up together with the team — and focused my work on the REST endpoints themselves: the routing, business logic, and data models.
- CRUD REST endpoints — the create/read/update/delete operations for the platform’s resources, implemented as FastAPI routers with typed request/response models, and pagination on the list endpoints so large collections come back in manageable pages instead of one huge response.
- Layered structure — a consistent organization where the HTTP layer handles routing and validation, a controller layer shapes responses and errors, a service layer holds the business/data logic, and Beanie/Pydantic models define the documents. Adding a new resource means following the same pattern, not inventing one.
- Validation & error handling — Pydantic schemas for every payload, with consistent, localized error responses so clients get predictable messages.
- Auth-guarded routes — endpoints protected behind the platform’s authentication (Amazon Cognito for user-facing calls and API keys for service-to-service), applied per route.
- Ownership checks — beyond authenticating the request, each one is authorized against the resource it touches: ownership comes from the validated token, not from the URL or payload, so a user can’t reach someone else’s record by changing an ID (IDOR protection).
- Idempotent writes — create operations are safe to retry, so a repeated request after a timeout or a double-tap resolves to the same record instead of silently creating a duplicate.
- DocumentDB data access — async access with Beanie/Motor (over the MongoDB-compatible wire protocol), including the query endpoints that back lookup and catalog features.
- Serverless & documented — the same FastAPI app runs locally and on Lambda (via Mangum), and every endpoint is self-documenting through FastAPI’s OpenAPI/Swagger UI.
Architecture
It’s the classic three-tier serverless REST pattern: API Gateway as the entry point — with a Cognito authorizer authenticating requests at the edge — invoking a FastAPI-on-Lambda service that runs each request through its uniform layered structure, with Amazon DocumentDB as the store and CloudWatch for logs and metrics. Because it’s serverless, the APIs scale up and down with traffic on their own; because the structure is uniform, every new resource slots into the same shape — authenticated and validated the same way.
Impact
The apps and internal tools got a consistent, well-structured REST surface to run the business on — validated, authenticated, authorized per resource (IDOR-safe), paginated, and safe to retry. The layered pattern made the API easy to extend: new resources reused the same shape instead of one-off code, keeping the platform’s API coherent — and secure by default — as it grew.
