I’ve been thinking about how we version APIs for ML and inference projects.
With model code, configuration, and deployment files already living in Git, it seems natural to keep the API contract there as well.
For example: model/code → OpenAPI specification → API tests → deployment
This is where the idea of a git-native API workspace becomes interesting to me.
Instead of designing an API in one place and synchronizing it with a repository later, the OpenAPI specification could be treated as a first-class Git artifact:
This seems particularly useful for inference APIs where endpoints, parameters, model versions, and response schemas can evolve quickly.
I’ve been experimenting with Apidog’s Spec-first workflow, where the Git repository can serve as the source of truth for OpenAPI specifications.
I’m curious how others are handling this.
For Hugging Face Spaces, Inference Endpoints, or custom model-serving APIs: Do you keep your API specification in Git alongside the model/application code?
Or do you prefer managing the API contract in a separate API workspace and syncing it with Git afterward?
I’d be especially interested in hearing from teams managing multiple models or frequently changing inference endpoints.