Need API Referential with Auto-Published Portal and Changelog
Need an asset database of APIs that auto-publishes specs and breaking-change changelogs into the systems developers actually use — Confluence, intranet, internal portal — because most enterprises do not yet have a true internal developer portal.
Take Control Of Your Signals — Become a Naftiko Design Partner Today!
Persona Story:
Riley is building the enterprise’s first real API referential — an asset database that knows every API, every version, every change — because there is no internal developer portal yet. The next step is publication: the referential has to push specs and breaking-change changelogs into Confluence so engineering teams can actually find them, since that is where the company already works. Every breaking change needs to land in front of the right consumers without anyone manually maintaining a wiki page.
Problem Context
- Most large enterprises do not have an internal developer portal yet, but they do have Confluence, intranets, and team wikis where developers live
- A change detector flags breaking changes back to developers, but downstream publication of those changes to consumers is still manual
- Practitioners are building an “asset database” / “API referential” from scratch as the source of truth — and need it to auto-publish, not just store
- Existing marketplace-style products do not solve the auto-publication-of-spec-and-changelog problem against the systems the enterprise already uses
Problem Impact
- Consumers find out about breaking changes from incident channels rather than from a published changelog
- Riley’s team is the manual integration layer between the referential and Confluence, burning time on copy-paste publication
- Governance work stays invisible to the rest of the company because there is no surface where it lands
- The referential becomes a parallel system that engineering ignores instead of the canonical truth
Naftiko Today
- Executable YAML capability specs are the asset records — every API ships with a single declarative source of truth that can be diffed across versions and published downstream
- Spectral ruleset (15 rules) and JSON Schema validation produce structured change reports that the referential can publish as auditable changelog entries
- Capability metadata (consumes, exposes, auth, parameters) gives the referential a normalized record per API that any portal or wiki publisher can render
- External bindings keep the referential’s publication targets — Confluence credentials, intranet endpoints — configurable without code changes
Naftiko Tomorrow
- HTML / Markdown format support (Second Alpha) will render capability specs and changelogs directly into Confluence-friendly formats with no intermediate transform
- Webhook adapter (Second Alpha) will let the referential push change events to subscribers (consumer teams, internal portals) as they happen
- JSON Schema Store publication (GA) will make the capability spec a discoverable artifact across tools that need to consume the referential
- Fabric capability discovery (v1.1) will let other teams query the referential as a first-class part of the enterprise capability fabric