Bazi Calculator API: Choose Hosted HTTP, Local MCP, or Source

A Bazi calculator API is not one category. For a public HTTPS request, compare the documented contracts at saju-api.pages.dev and Sazu Manse API. For a local tool, OpenFate BaZi MCP runs as a stdio process. For calculation code in your own runtime, jaeyeonling/saju-ts is a local TypeScript library. An owned Korean Saju source pack is a different purchase: it is a web-app starting point with buyer-owned deployment, not a hosted API or MCP. This comparison uses public documentation and repository metadata checked on 2026-09-06. No provider signup or API call was made.

What should you choose first?

Choose the boundary before comparing output names. Hosted HTTP is the fit when your application needs a remote request, a provider key, and a provider-defined schema. Local MCP is useful when an AI client can launch a local stdio server and call its tools. A local library gives your code direct ownership of the integration. An owned source pack starts further up the product stack: UI, application flow, and deployment decisions are yours to operate. If an existing backend only needs JSON, evaluate hosted HTTP first; if you need an owned Korean UI and brand and can operate Node and D1, evaluate the owned source route.

Click image to enlarge.

What do the hosted API documents actually establish?

The saju-api quickstart documents a REST calculation request at POST https://saju-api.pages.dev/api/v1/calculate. It shows an X-API-Key header and fields including year, month, day, hour, gender, and language; its documented example uses hour: -1 for an unknown birth hour and says lang defaults to ko. That is enough to classify it as a hosted HTTP integration candidate, while uptime, pricing, and compatibility with a particular Korean time convention remain separate questions.

The Sazu documentation is dated 2026-09-01. It describes a hosted calculate endpoint, birth fields, and a true-solar-time option. Its plan notes distinguish fixed sample profiles in the free sandbox from paid real birth calculation. Treat that as a plan and input boundary to verify with the provider; it does not settle how its semantics match another Bazi or Korean Saju implementation.

What is different about local MCP and library options?

The OpenFate README presents a local stdio MCP setup using npx -y @openfate/bazi-mcp and a calculate_bazi_chart tool. Its documented inputs include calendarType, timezoneId, and dayBoundaryMode. The useful decision fact is the transport: your MCP client launches a local process.

The saju-ts repository is a local TypeScript library, and its primary GitHub metadata reports an MIT license. That can make it relevant when you want code in your own runtime. You still need to inspect maintenance, integration surface, output behavior, and notices for your project. A local library is not a ready-made hosted API.

What should you record before choosing?

Use the selection checklist to record the answers instead of relying on a product name.

Input and time rules. List every required field. Check whether the docs mention timezone, true solar time, daylight saving, lunar conversion, or Korean-specific handling. Preserve documented distinctions such as an unknown hour: -1, a default lang: ko, and OpenFate’s calendarType, timezoneId, and dayBoundaryMode; callers should not normalize them away. Missing documentation is an unknown, not permission to fill in a rule.

Access and cost. Separate API-key mechanics from plan limits. A free sandbox may be sample-only. Record paid requirements as documented and leave production totals unknown until you verify them. Do not turn a sample response into a benchmark.

Runtime and rights. Hosted HTTP moves the request boundary to a provider. MCP and libraries move more runtime work to your machine. An owned source pack moves deployment and configuration to the buyer. Record the license or commercial terms from the primary source and check privacy, legal, and third-party notices before using birth data.

What does a completed comparison look like?

The completed document comparison records the four public developer sources and the owned Korean Saju source boundary. Its decision is deliberately conditional: hosted HTTP needs provider access and plan review; local tools need runtime and integration review; an owned source pack needs buyer-owned deployment and product review. The document comparison itself is complete, while runtime execution remains outside its evidence.

Where can this comparison mislead you?

“Bazi,” “Saju,” and “Four Pillars” are related labels, not a promise of identical calculation or time handling. A REST field list, an MCP tool schema, and a TypeScript package description are different kinds of evidence. I did not rerun provider tests or measure accuracy or speed, and I did not verify any benchmark a provider page may advertise. The free Sazu path is described as sample-limited, while arbitrary real-birth calculation is documented as paid; do not assume another provider follows that model. Human review is still needed for privacy, legal, third-party, license, and production settings.

Before a production decision, write down the smallest test that can disprove your assumption. For a hosted API, that might be a schema review using documentation and a provider-approved sandbox. For a local MCP or library, it might be a clean install in a disposable project, followed by inspection of inputs and outputs. For an owned source pack, it might be a local run through the intended Korean birth-date flow before buyer-owned D1 and DNS configuration. Keep that test separate from a claim that the system is accurate or production-ready. The purpose is to expose missing fields, time-rule questions, license gaps, and data-handling work early.

If you need an owned Korean Saju web-app starting point, review the Korean Saju source pack.