Skip to main content
These are further out than the planned endpoints — capabilities we haven’t built yet, even internally. They’re here so partners can react to the shape of what’s coming and tell us what matters. Anything shown as a shape is illustrative, not a contract — field names and structures will change.
Nothing on this page is commercially available yet. Preview items are provisioned with you as we open access; roadmap items aren’t built. Tell us which you’d build against.

Per-organization API keys

Preview — provisioned during onboarding; no self-serve endpoint yet.
An org-scoped API key so external clients authenticate as your organization rather than depending on an individual user’s JWT. We’d provision and scope it with you as we open access; self-serve issuance and rotation are planned. Open questions we’d like your input on: what scopes you’d want (capture-only, read-only, per-team), rotation expectations, and whether you need multiple keys per org.

Retrieval / read endpoints

Roadmap — not built yet; shapes shown are illustrative, not a contract.
The first surface is write-and-trigger: you’d send captures and get back ids and status, but there’s no way to read the data model back out. Planned read endpoints would let you pull captures, sessions, game events, game stats, and roster for a team. We’d like to know which objects you’d read most, and whether you need filtering (by session, by player, by date) or just bulk sync.

Webhooks

Roadmap — not built yet; shapes shown are illustrative, not a contract.
A way to subscribe to changes — a capture being classified, a game being finalized, a stat being derived — rather than polling. Tell us which events would drive your integration and what delivery guarantees you’d need.

Audio ↔ tagged-timeline alignment

Roadmap — not built yet; shapes shown are illustrative, not a contract.
Aligning a capture’s audio and observations to a game clock and event timeline, so a spoken note resolves to a precise moment (period + game-clock offset) and can be lined up against other timelined data.

Video ingestion

Roadmap — not built yet; shapes shown are illustrative, not a contract.
This is the surface we most want partner feedback on. The intent is to bring game video into the same player-and-game model that voice notes, stats, and events already feed — so everything references one timeline. We’re thinking about it along a few axes.

Streamed vs. offline-captured-and-synced

  • Streamed — live or near-live game video delivered as the game happens.
  • Offline-captured and synced — video captured out of band (an arena camera, a phone, a third-party system) and uploaded or synced to RinkNotes after the fact.

Raw vs. tagged / classified

  • Raw video — you send the footage and RinkNotes derives the event and observation timeline from it.
  • Pre-tagged / classified video — you already have events, shifts, zones, or timestamps from your own system, and RinkNotes aligns them to its player and game model rather than re-deriving them.

Timeline sync

However video arrives, the goal is to align it to the existing capture and game-event timeline — session_id, period_id, and game_elapsed_ms — so voice notes, stats, and video all reference the same clock and a moment in one shows up alongside the others.

What we’d want to hear from you

Formats

What containers and codecs your video comes in, and typical file sizes / stream types.

Tag shape

If your video is pre-tagged, how those events / shifts / zones / timestamps are represented.

Sync anchor

How you’d expect video to line up — wall-clock, game-clock, or a manual offset.

Delivery

For streamed video, your latency and delivery expectations.

Tell us what matters

Shape the roadmap

Tell us which of these you’d build against, and how your video and tags are shaped — it directly informs what we build next.