APIPark: an AI gateway and API developer portal that installs with one curl command

The problem APIPark targets: many model vendors, one internal API surface

Most teams that add LLM features end up with the same mess. One service calls OpenAI, another calls Claude, a third calls a domestic Chinese model. Each SDK has its own request shape, its own key handling, its own error format. When a model is deprecated or a cheaper one appears, every caller has to change.

APIPark's answer is to put a gateway in front. The README states the project connects to 100+ AI models and standardizes the data format of all AI API requests, so switching models or editing prompts does not touch the calling application. It also packages a prompt template plus a model into a new REST API, which the README illustrates with a sentiment analysis API or a translation API built on OpenAI GPT-4.

The audience is narrower than the tagline suggests. This is for platform teams inside a company that already has internal APIs and now needs to add AI to them, and for teams that want an internal developer portal with API keys, subscriptions and approval workflows. A solo developer with one model and one endpoint gets little from it.

Go gateway, TypeScript frontend, and what the repository layout implies

The repository layout is the clearest description of the architecture. There is a gateway/ directory, a frontend/ directory, and Go source files at the top level including main.go, init.go and initialization.go. The frontend is TypeScript, which matches the primary language reported for the repository.

The Go module file lists the concrete dependencies. MySQL appears through github.com/go-sql-driver/mysql, InfluxDB through github.com/influxdata/influxdb-client-go/v2, NSQ through github.com/nsqio/go-nsq, and Redis indirectly through dgryski/go-rendezvous. There is an OpenAPI dependency (getkin/kin-openapi), a Gin HTTP stack, GORM for persistence, and github.com/mark3labs/mcp-go, which is an MCP implementation. A separate mcp-server/ directory sits at the top level.

That combination tells you what the deployment expects: a relational database for configuration and metadata, a time-series store for call metrics, a message queue for asynchronous work, and a cache. The README does not document which of these quick-start.sh provisions versus which you must supply, so treat the dependency list as a checklist rather than a specification. The presence of an MCP server directory is the most interesting detail, because it suggests APIPark can expose APIs to agents rather than only to human-written code, though the README's roadmap lists AI agent integrations such as Langchain and Dify as future work.

Installing APIPark with the quick-start script

The README gives exactly one installation path. It is a shell script downloaded and executed in the same line, and the README claims the AI gateway and developer portal are deployed in under 5 minutes.

curl -sSO https://download.apipark.com/install/quick-start.sh ; bash quick-start.sh

Running that downloads quick-start.sh from download.apipark.com into the current directory and executes it. Because the script is fetched over HTTPS and then run with bash, you should read it before executing it, and you should not run it on a machine where you are unwilling to have a container or service installed. The README does not state which ports the gateway and portal listen on, which volumes are created, or how to uninstall, so plan to inspect the script or the resulting containers for those details.

The repository also carries a .gitlab-ci.yml at the top level, and scripts/ and resources/ directories, which is where build and packaging logic lives if you prefer to build from source rather than use the hosted installer. Building from source means working with Go 1.23.4 as declared in go.mod and producing the TypeScript frontend separately.

Once the portal is up, the first real task is registering a model provider and publishing an API from it. The README describes the result rather than the clicks: you connect an AI model, combine it with a prompt template, and the portal publishes that combination as a REST API that other applications subscribe to and call with a key. The README does not include a screenshot-level walkthrough of that flow, so expect to work from the portal UI itself.

Where APIPark is the wrong tool

The release history is the first thing to weigh. The three most recent releases listed are v1.9.6-beta, v1.9.5-beta and v1.9.4-beta, all tagged as beta. If your organization requires a stable tagged release before a gateway goes in front of production traffic, APIPark does not currently offer one. The repository is not archived and the last push was on 2026-09-09, so the code is moving, but movement is not the same as a stable release channel.

The second limitation is operational weight. A gateway that wants MySQL, InfluxDB, NSQ and Redis is a system, not a binary. If you are running one service that calls one model, you are adding four stateful dependencies to remove an SDK dependency. That trade is usually bad.

The README's performance claim, that APIPark outperforms Nginx, is not accompanied by a methodology, a hardware description or a reproducible benchmark. Treat it as a vendor claim. The same applies to the compliance and security language in the use cases section, which names granular permission management and approval workflows without describing the underlying model. Multi-tenant management is listed as a feature, but the README does not explain how tenants are isolated, whether by database schema, row-level filtering or separate deployments. If tenant isolation matters to you, that gap is a reason to test before adopting, not a reason to assume either answer.

APIPark compared with a single-purpose LLM proxy

The closest alternative in the related searches is an LLM gateway that only proxies model traffic, such as BricksLLM. The difference in approach is scope. A dedicated LLM proxy does one job: it accepts OpenAI-shaped requests and forwards them to whichever provider you configured, handling keys, retries and fallback. It typically needs one process and one datastore at most.

APIPark does that job and then adds a general REST API gateway, an API developer portal, subscription and approval workflows, multi-tenancy and analytics. The gateway/ directory and the API lifecycle features in the README are the evidence that the REST side is first-class rather than an afterthought. That is the actual distinction: with a single-purpose proxy you manage model routing, and with APIPark you manage model routing plus the catalog of everything else your teams expose.

If your problem is only that five services each hold an OpenAI key, a proxy is the smaller answer. If your problem is that internal teams cannot find, request or audit each other's APIs, and AI endpoints are one more category in that catalog, APIPark's breadth is the point. The cost of that breadth is the dependency list described above.

Licence, upgrade cost and what beta tags mean for you

APIPark is licensed under Apache-2.0, and the README states it is free for commercial use. Apache-2.0 includes an explicit patent grant and permits modification and redistribution, which matters if you intend to fork the gateway or embed it in a product. It also means you carry the obligation to preserve licence notices and to state significant changes if you redistribute a modified version. That is a summary of the licence text, not legal advice; have counsel review it if you are redistributing.

Upgrade cost is where the beta tags bite. Every listed release is a beta, and the version numbers move in the 1.9.x line. The README does not document a migration path between versions, does not mention database schema migrations, and does not describe rollback. Because the deployment depends on MySQL and InfluxDB, an upgrade presumably involves schema state, but the README does not say how that is handled. Before you upgrade a running instance, check what the release notes for that specific tag say and whether the installer supports an in-place upgrade at all.

The practical consequence: pin the version you deploy, keep a database backup you can restore independently of the application, and do not assume that a patch release is drop-in. The project does not currently give you the documentation to assume otherwise.

Editorial conclusion

Adopt APIPark if you need one gateway that fronts both LLM providers and your own REST services, and you want a portal for API keys, subscriptions and approvals without building one. Skip it if you need a stable tagged release today, since the most recent releases are all beta versions, or if you only need to proxy a single OpenAI-compatible endpoint, where a lighter proxy is less to operate. Before committing, verify the default ports and data volumes created by quick-start.sh, and confirm which database and queue the container expects, because the README does not document either.

Frequently asked questions

Official sources

1. APIParkLab/APIPark on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases