Skip to main content

​
Tattoo Developers

tattoo.co chrome sigil Developer docs by Tattoo Company for governed TattooAPI surfaces across tattoo.co, Studio OS, and tattoo.dev. These docs are intentionally dark-mode first: chrome-on-ink, glass panels, cyber-sigil accents, and a narrow public surface that does not overclaim what is live.

Ontology Kernel

The canonical tattoo domain model, projection contracts, trust posture, and review lanes.

API Surface Map

Public reads, authenticated beta reads, owner projections, and blocked write boundaries.

Studio Middleware

TattooAPI is the bridge between tattoo.co, Studio OS, managed websites, source packs, and future SDKs.

Governed Hydration

External data enters as source packs, then moves through review, preview, and approval before runtime truth.

Wave Gates

Public SDKs, pages, datasets, and intelligence tasks stay gated until runtime and review proof are ready.

Project Status

Current access posture, public boundaries, beta reads, and launch constraints.

​
Product Model

TattooAPI is not the Studio OS app and not the tattoo.co marketplace. It is the governed kernel between them.
  • tattoo.co: consumer marketplace and booking conversion.
  • Studio OS: private studio-owner operating app.
  • TattooAPI: ontology, projections, access control, source-pack, and integration contracts.
  • tattoo.dev: developer portal, SDKs, and app-channel documentation.

​
What Exists Today

  • A repo-native ontology package at packages/domain-ontology
  • Generated reference material in project-context/ontology
  • A governed runtime layer for internal execution, with remaining legacy paths being isolated
  • A transitional public API surface for health and studios, with authenticated beta reads
  • Internal SDK and operator workbench layers that are moving toward governed runtime truth
  • A large studio, artist, and portfolio corpus that is being staged and normalized with explicit provenance
  • Private worker and operator tooling that follows the same access boundaries as the API

​
Build Order

1

Ontology First

Lock the object model, taxonomies, relationships, governance, and trust fields.
2

Normalize Data

Map the existing studio and artist corpus into canonical records with explicit recordState.
3

Stabilize API

Document and harden only the endpoints that are real today.
4

SDK and Tools

Project the stabilized contracts into SDKs, partner tools, and reviewed workflows.

​
Start Here