Overview

jamie-api is a thin wrapper around Jamie's official developer API:

• Official Jamie API docs
• GitHub repository

The goal is not to invent a different platform. The goal is to make Jamie's API easier to consume by exposing a clearer typed contract, generated reference docs, and a single place to handle the transport details.

What This Wrapper Does

• Preserves Jamie's core API concepts like personal vs workspace keys
• Keeps the same authentication model with the x-api-key header
• Exposes the API through a typed oRPC router and OpenAPI docs
• Normalizes the public contract where a local shape is clearer than the raw upstream transport shape

In practice, that means you can build against a public contract that feels intentional without losing sight of the upstream Jamie API it sits on top of.

What "Transparent" Means Here

This wrapper is designed to stay close to Jamie instead of hiding it.

Transparency in this project means:

• You can still reason about the API in Jamie terms: meetings, tasks, tags, personal keys, and workspace keys
• The route families stay explicit: /v1/me/* for personal access and /v1/workspace/* for workspace access
• Authentication is passed through using the same x-api-key header Jamie expects
• The wrapper does not add product-specific abstractions unless they improve the public contract

If you already understand the official Jamie API, this layer should feel familiar. If you do not, the docs here should still be enough to get started without reverse-engineering raw tRPC request shapes.

How It Works

1. Your client sends a request to this wrapper.
2. The wrapper validates inputs and documents the public request and response shapes.
3. The wrapper forwards the request context, including headers and API keys, to Jamie's upstream API.
4. The response is returned through a documented contract that is easier to inspect, type, and evolve.

This is why the project can stay transparent and still be useful: it keeps the upstream behavior recognizable while improving the developer-facing contract.

Why Use This Instead Of The Raw Upstream Surface

• Clearer request and response schemas
• OpenAPI docs and RPC procedures generated from the same router
• A better place to normalize awkward transport details
• One public surface to review, test, and evolve

Use the official Jamie docs as the upstream source of truth, and use this wrapper when you want a typed, documented, consumer-friendly interface around that API.

Start Here