Skip to main content

​
Tattoo Developers

tattoo.co chrome sigil Developer docs by Tattoo Company for the governed TattooAPI, tattoo.co, Studio OS, and future tattoo.dev platform. 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, WorkOS-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 runtime posture, Convex authority, WorkOS beta auth, Mastra/MCP internals, 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, projection, auth, source-pack, and middleware contracts.
  • tattoo.dev: future 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 self-hosted Convex target runtime for internal execution, with remaining legacy paths being isolated
  • A transitional public API surface for health and studios, with WorkOS-authenticated internal beta reads
  • Internal SDK and operator workbench layers that are moving toward Convex-backed runtime truth
  • A large studio, artist, and portfolio corpus that is being staged and normalized with explicit provenance
  • Mastra and MCP internal tooling that use WorkOS identity plus Convex actor mapping

​
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 Agents

Project the stabilized contracts into SDKs, tools, and workflow orchestration.

​
Start Here