Media Registry

Documentation

Learn how to use OCME Registry for content creation and verification

Reference

Content Verification

Verify the authenticity of OCME content and creator identities.

Verify Content

Integration Guide

OCME Registry offers three integration surfaces, from fully public verification to the authenticated partner API. Pick the surface that matches your use case.

1. Public Verification (No Authentication)

Anyone can verify OCME content and identities. Use POST /api/verify/did to resolve and cryptographically verify any registry DID in one call, or fetch the raw DID document from the public resolution endpoints:

  • • GET /creator/{id}/did.json
  • • GET /member/{hash}/did.json
  • • GET /showrunner/{slug}/did.json

Public responses are privacy-redacted: payment and legal-identity fields are stripped, and the document proof is removed whenever anything was redacted (disclosed in a publicRedaction block). The verified result from /api/verify/did is computed internally against the full document and remains trustworthy. Browser-based tools live at /verify.

2. Service-Binding API (Partners)

The /service-binding/* API is the registry's partner surface, restricted to the trusted internal binding contract (the RIC gateway). Integration requires:

  • • Authentication — a JWT issued by the OCMECO app, validated server-side through the Sentinel auth service on every request.
  • • Roles — creator, broadcaster, or admin; each endpoint enforces per-method role requirements (for example, creators see only their own content).
  • • Capability — content CRUD and lifecycle, creator profiles and search, DID minting, playlists, sites and showrunners, play records, notifications, and revenue dashboards.

See the API Reference for the endpoint inventory. Access is arranged through the OCME partnership channel, not self-serve.

3. The Content Pipeline

  1. 1. Upload — creators upload through the OCMECO app. The registry mints the DID set for the upload (content, media, splitsheet) via POST /service-binding/did/create-upload-dids and records the content graph in canonical D1 storage. Every content record carries a default solo splitsheet (the uploader at 100%) unless collaborators are named.
  2. 2. Registry-first fanout — registry writes propagate through Cloudflare Queues (RIC sync and projection) to downstream broadcast and catalog surfaces. The registry is the system of record; consumers receive projections.
  3. 3. Broadcast and play records — broadcast sites air content; play events are recorded against the content DID and feed revenue settlement.
  4. 4. Settlement — settlement periods allocate revenue per splitsheet shares; payout reports and receipts are admin-governed.

Next Steps

API Reference Getting Started
Next: System Overview