build on task data the server cannot read

init.Tasks API

init.Tasks is a to-do app that looks like a terminal. This is its public API: a REST surface at https://api.inittasks.com/v1, and an MCP server so an AI client can use the same data under the same permissions.

It is free, and there is no approval process for your app.

The server cannot read your tasks

Every content field is encrypted on the user's device before it is stored. Titles, descriptions, tags, dates, file names and attachment text are ciphertext in the database, and the key never reaches the server in a form the server can use on its own.

When you call this API the credential you hold carries the key, and the server decrypts for your requests only, in memory, keeping nothing on disk. So:

You get plaintext. GET /v1/todos returns real titles.
There is no server-side search over content. /v1/search runs after decryption, inside your request.
There is no todo.completed webhook. status is encrypted, so the server cannot tell a completion from a rename.
A database backup holds only ciphertext, and so does anyone who reads the database, an administrator included.

Anything that would need the server to understand content does not exist here. Encryption has the details, and it is the page to read before you design anything.

Which door

you are	start at
connecting Claude, ChatGPT, Cursor or any other AI to your own tasks	connect an AI
writing code against the API	quickstart
writing an MCP client for other people	MCP

Two kinds of credential

	for	how
Personal access token	your own scripts, a cron job, one-off automation	create one in the app, paste it into your code
OAuth 2.1	an app other people will use	register, send the user to approve, get a token

Both carry scopes, both are revocable, and both stop working the moment the user changes their encryption key. A password change leaves them working. See authentication.

Concepts worth reading once

The data model: containers, to-dos, notes, the inbox, and what the views mean.
Dates and time zones: four date fields, and whose day the views use.
REST and MCP: the same data through two surfaces, and where the words differ.
Trash and deletion: what is recoverable and what a container takes with it.
Keeping a copy in sync: backfill, sweep, and where webhooks fit.

The shape of the API

The base URL is https://api.inittasks.com/v1. JSON in and out, except a file's bytes: an upload can send the raw file, and /file routes answer with it.
/oauth/*, /.well-known/*, /healthz and /openapi.json sit at the host root. They are not versioned data.
/v1 is the current version. See versioning for what can change and how you hear about it.
Errors are RFC 9457 problem+json. Branch on type. See errors and retries.
Lists are cursor-paged, apart from a few short ones that answer in full. See pagination and filtering.
GET https://api.inittasks.com/openapi.json is the machine contract, and every response links to it.