Skip to content

Numerology API v1.0.3 Changelog

Numora Studio v0.1.0-beta

Release date: 2026-08-22
Version: v1.0.3
Scope: Zodiac sign intelligence, planetary report reliability, Birth Day corrections, on-demand translation providers, and the first Numora Studio desktop beta.

v1.0.3 is a product-facing release across the direct API and its practitioner tooling. It adds a complete zodiac sign reference surface, makes planetary report behavior more predictable, improves a core numerology endpoint, and gives horoscope-report consumers explicit control over on-demand translation providers. It also introduces Numora Studio v0.1.0-beta for macOS, Windows, and Linux.

Release highlights

  • Added dedicated Zodiac Sun Sign, Moon Sign, Rising Sign, Modality, and Element endpoints.
  • Standardized planetary report requests around the general planet option and made it the default where a planetary selection is required.
  • Fixed Birth Day Number request and meaning-resolution issues while preserving GET and POST parity.
  • Added full birth-chart SVG wheel customization, including presets, themes, custom palettes, panel layout, visibility controls, typography, planet colors, split output, transparent backgrounds, and compression options.
  • Added full on-demand translation routing for horoscope-report responses, with self-hosted LibreTranslate, Google Translate, and DeepL BYOK support.
  • Added provider observability through _api_metadata_.translation_provider for translated responses.
  • Released Numora Studio v0.1.0-beta for macOS, Windows, and Linux practitioners.
  • Bumped the runtime FastAPI/OpenAPI version and standardized response metadata on v1.0.3.

New

Zodiac sign intelligence

The API now exposes five dedicated zodiac reference families under /api/v1/horoscope/sign/. Each family is authenticated, usage-tracked, localized through the shared response pipeline, and available through both GET and POST where the endpoint contract supports a body request.

Family Routes Purpose
Sun sign /api/v1/horoscope/sign/sun Reads the Sun sign from a birth date or an explicit sign and returns identity, vitality, purpose, compatibility, and sign facts.
Moon sign /api/v1/horoscope/sign/moon Returns the emotional, instinctive, intuitive, and inner-world reading for a Moon sign.
Rising sign /api/v1/horoscope/sign/ascendant Returns the Ascendant/Rising Sign reading for public persona, first impressions, outer expression, and direction.
Modality /api/v1/horoscope/sign/modality Groups signs by cardinal, fixed, or mutable and returns the modality expression for each sign.
Element /api/v1/horoscope/sign/element Groups signs by fire, earth, air, or water and returns the elemental expression for each sign.

All five families return structured sign facts, symbols, archetypes, summaries, detailed meanings, and an enterprise usage wrapper. They are designed to work independently for lightweight integrations and alongside birth-chart or horoscope-report workflows for richer practitioner experiences.

Translation provider routing

Horoscope report responses can now be translated on demand without requiring a separate pre-generated payload for every request. The translator can be selected per request with the translator query parameter or the X-Translator-Provider header:

  • LibreTranslate — the default self-hosted provider for production report translation.
  • Google Translate — the built-in Google-backed provider for supported language pairs.
  • DeepL BYOK — use your own DeepL key with translator=deepl and the X-Translator-Api-Key header.

The translator used for a non-English response is reported in _api_metadata_.translation_provider. The existing language negotiation remains compatible with the lang query parameter and the Accept-Language header, and the response still reports the resolved language in _api_metadata_.response_language.

Example:

POST /api/v1/horoscope/reports/monthly?lang=fr&translator=deepl HTTP/1.1
X-API-Key: tnea_your_key
X-Translator-Api-Key: your_deepl_key
Content-Type: application/json

The same routing is available for engine-backed horoscope reports and birth-chart responses. English responses remain untranslated and do not incur translation-provider work.

Birth-chart SVG wheel customization

The /api/v1/birth-chart/svg endpoint now accepts a complete wheel customization object instead of limiting integrations to a small set of visual aliases. Clients can select a supported preset or theme, override the palette and accent color, control panel layout and opacity, toggle chart labels and visual layers, set title and subtitle text, provide per-planet colors, and choose split, transparent, or compressed SVG output. The endpoint keeps the existing birth-chart calculation options—zodiac system, ayanamsa, house system, node type, language, and locale—alongside the wheel controls.

Supported theme presets include night, day, aurora, paper, obsidian, sunset, zenith, mono, and custom. Custom themes must provide a valid palette, while size and opacity fields are validated before the request reaches the chart engine. Existing top-level theme aliases remain accepted for compatibility.

Numora Studio v0.1.0-beta

The first practitioner desktop release is now available as Numora Studio v0.1.0-beta for:

  • macOS
  • Windows
  • Linux

Numora Studio uses the API's dedicated Studio channel and supports the new zodiac and horoscope-report capabilities in a practitioner-oriented workspace. Studio requests identify themselves with X-Numora-Client: numora-studio/<version> and use tnsr_ keys so Studio usage is metered independently from platform tnea_ keys.

The beta is intended for real workflow testing and feedback. Integrators should keep the desktop client version visible in diagnostics and should not reuse Studio keys in browser or server-side platform integrations.

Fixes

Planetary reports

  • Added general to the canonical planetary option set.
  • Made planet: "general" the default in planetary section and overview request models.
  • Kept the general overview routes explicit and stable across daily, weekly, monthly, and yearly periods.
  • Preserved validation for non-general report sections so clients receive a clear error instead of a silently ignored section.
  • Kept legacy aliases available where they remain part of the compatibility surface while directing new clients to /api/v1/horoscope/reports/planetary/*.

Birth Day Number

  • Corrected date parsing and validation for the YYYY-MM-DD request contract.
  • Fixed meaning lookup so all valid calendar days resolve through the detailed Birth Day catalog.
  • Preserved the structured response fields birth_day_number, keyword, meaning, detailed_meaning, and summary.
  • Kept GET and POST behavior aligned, including authentication, usage tracking, enterprise metadata, and localized response formatting.

Response consistency

  • Standardized the runtime version exposed by FastAPI/OpenAPI and shared response metadata to 1.0.3.
  • Preserved _enterprise and _api_metadata_ as separate wrappers so existing clients can continue parsing billing and integration metadata independently from report content.
  • Continued to report the selected translation provider only when translation work was performed.

Response metadata contract

Every response produced through the shared API response helper now reports:

{
  "_api_metadata_": {
    "api_name": "The Numerology API by Dakidarts®",
    "api_version": "1.0.3",
    "endpoint_name": "...",
    "response_language": "...",
    "supported_languages": ["..."],
    "translation_provider": "..."
  }
}

translation_provider is included for translated engine/report responses and is omitted for English or non-translated responses. The metadata timestamp, endpoint description, documentation URL, and issue-report URL remain available as before.

Compatibility notes

  • v1.0.3 is additive for the new zodiac families.
  • Existing numerology and horoscope paths remain available unless explicitly marked as compatibility aliases in their endpoint documentation.
  • Existing birth-chart SVG clients remain compatible; new integrations can progressively adopt the wheel object for full visual control.
  • Existing clients that ignore unknown response fields remain compatible.
  • Clients should not hard-code the metadata version; read _api_metadata_.api_version when displaying diagnostics or support information.
  • DeepL BYOK users must keep their API key server-side or in a controlled integration boundary and must not expose it in browser-delivered code.

Documentation and validation

  • Added the v1.0.3 release note to the dashboard's internal MkDocs reference.
  • Refreshed the public documentation release index and localized release pages.
  • Added Numora Studio imagery to the release documentation.
  • Documented the full birth-chart SVG wheel customization contract and its compatibility aliases.
  • Validated zodiac route registration, planetary request defaults, response metadata, translation-provider reporting, and Birth Day GET/POST contracts.