---
title: "Why We Use FastAPI at Sugra"
description: "We built our first API on a custom Python stack. FastAPI turned request parsing, validation, and documentation from a recurring checklist into a single declaration."
seo_title: "Why We Use FastAPI at Sugra"
seo_description: "Nearly two hundred sources sit behind Sugra API. One FastAPI declaration checks each parameter and writes that check into the OpenAPI schema."
slug: why-fastapi
status: published
published_at: 2026-10-07
author: Arman Obosyan
author_url: https://sugra.systems/about
section: general
primary_keyword: FastAPI Sugra API
hero_image: /blog/images/posts/why-fastapi/desk.png
hero_alt: "Night desk with three monitors, a warm lamp, a full keyboard, a mouse, and a black cup."
og_image: /blog/images/posts/why-fastapi/desk.png
tags:
- fastapi
- engineering
- api
---
This year, Sugra Systems, Inc. became a Silver Sponsor of [FastAPI Conf](https://fastapiconf.com/), taking place on October 28 in Amsterdam. We build on [FastAPI](https://fastapi.tiangolo.com/), benefit from the team's work, and want to support the community around it.
We built the first version of Sugra API on our own custom Python stack. Python, a custom API implementation, Gunicorn. We knew the code and could change any part of it whenever we needed to.
That also meant maintaining everything around it. Parse the request parameters, validate the values, handle errors, prepare the response, update the documentation. Then add another endpoint and work through the same list again.
Over time, the repetition became difficult to manage. We had built it, we knew how it worked, and we remembered which places needed updating. That arrangement works for a while. As a project grows, your own memory becomes a fairly unreliable part of the architecture.
Sugra API brings together data across finance, economics, weather, news, research, and other domains. Behind that interface are nearly two hundred sources, each with its own format, limits, and peculiarities. Working with the data itself gives us plenty to do. The foundation we use to build the API has a very practical effect on how much time we can spend on that work.
We moved to FastAPI.
One thing I particularly appreciate is how parameter definitions, validation, and documentation fit together. You declare types and constraints in Python, and the framework uses those definitions to process requests and generate the OpenAPI schema. The interactive documentation comes from those definitions too.
It sounds like a convenience until you have maintained those pieces yourself.
Take a simple endpoint that accepts a record count between 1 and 100. In a custom implementation, that can mean several separate jobs: read the value, convert it to a number, check the range, return a useful error, and document the restriction. When the rule changes, you need to revisit those places.
With FastAPI, the type and range can be declared alongside the parameter. That definition drives both request validation and the generated API description. There are fewer places to keep in sync.
```python
# By hand
def get_records(params):
raw = params.get("limit", "20")
try:
limit = int(raw)
except ValueError:
return {
"status": 400,
"detail": (
"limit must be an integer"
),
}
if limit < 1 or limit > 100:
return {
"status": 400,
"detail": (
"limit must be "
"between 1 and 100"
),
}
return {"limit": limit}
```
```python
# FastAPI
from typing import Annotated
from fastapi import FastAPI, Query
app = FastAPI()
@app.get("/records")
def get_records(
limit: Annotated[
int,
Query(ge=1, le=100),
] = 20,
):
return {"limit": limit}
```
*The same limit. Written out, or declared once.*
On Sugra that declaration does not stop at the request. The OpenAPI document it produces is published with the API. The operation catalog our MCP server exposes is built from that document. Add an endpoint, or change the range on a parameter, and the catalog moves with the code. There is no second copy of the rule to remember.
For me, this is one of many reasons to use FastAPI. Similar capabilities exist in other tools. What I appreciate here is how naturally they work together in everyday Python code.
Response models follow the same approach. With Pydantic, you can describe the expected structure and validate responses against it. For a data service, that is useful discipline: define what the client receives, which fields are required, and which values are allowed.
A valid structure does not establish that a source has supplied an accurate figure. Source quality, normalization, and the meaning of the data remain our responsibility. FastAPI helps us maintain a clear contract at the boundary of that work.
*Figure 1. A valid structure is not a true figure.*
Shared checks and parameters can be dependencies, reused across operations, and what they declare becomes part of the OpenAPI schema. A small detail, until the API grows.
Anyone who has maintained an API by hand knows the failure: the code moves, and the written description stays where it was. Generating the schema from the declarations narrows that gap. Explanations and examples are still written by hand.
For someone integrating Sugra, the interface is easier to read. For us, there is less to keep in sync by memory.
Much of the work is waiting on other servers. With suitable non-blocking libraries, FastAPI can use that wait. Timeouts, caching, connection management, and source limits still need careful engineering.
As someone with a technical mindset, I appreciate the clarity this brings to the code. As a founder, I also care about where the team's time goes. Every custom piece of supporting infrastructure needs maintenance, explanation, and testing when things change. That has a cost, even when it never appears as a separate line in a budget.
FastAPI gives us more room to focus on Sugra itself: connecting sources, handling their differences, and making the data more useful to the people building with it.
I remember how much work went into our first API. So when I use FastAPI, I can appreciate the work behind it: the design decisions, the documentation, and the ongoing effort required to maintain the project.
Thank you to [Sebastián RamÃrez](https://tiangolo.com/) ([@tiangolo](https://x.com/tiangolo)), the [FastAPI](https://fastapi.tiangolo.com/) team, and everyone who contributes to the project. Some of the work we once had to do by hand is now handled by tools you built and maintain.
You can see what we are building on that foundation in the [Sugra API documentation](https://docs.sugra.ai/).