Build on pipeit: your own clients and the API

One shared contract for all clients

Sending files, destination rights, group transfers, receiver status and allowed follow-up actions come from the existing pipeit backend. A new client should not invent a second sign-in, its own meaning for “delivered” or a silent server-route fallback. Local cryptography, file access and resuming belong in the shared client libraries and their interoperability tests.

For automation, use the existing CLI first. For your own client, the OpenAPI description is the interface contract. Generated types, SDK version and server capabilities have to fit together.

A technical way in

1. Decide the client profile: browser, native sender, permanent receiver or MCP application.
2. Use the existing authorization flow. Native devices get a browser approval; remote MCP uses the documented OAuth flow.
3. Read capabilities and permissions. Offer only profiles and destinations that are actually available.
4. Prepare jobs with stable IDs and a bound recipient. Keep destination revision and route across a resume.
5. Encrypt file blocks locally, or verify them at the receiver. Reaching a byte counter is no proof of delivery.
6. Evaluate verified receipts, signed receiver problems and allowed next steps.
7. Test failures, lost responses, revocation, restart and resume in your own client. Backend tests do not replace that.

OAuth and file rights, kept apart

An MCP client can be registered without being allowed to see any device. Only consent and a destination grant allow the concrete action. A send right contains no right to delete folders. A file path in a chat is no access to that local file. Changes to context or default destinations need rights of their own and do not alter a transfer that has already been prepared.

pipeit connects to ChatGPT, Codex, Claude, Gemini and Grok as a custom MCP connector. The MCP address, provider commands and the tool scope are in Connect ChatGPT, Codex, Claude, Gemini and Grok.

For a bug report, a synthetic reproduction, the version, the operation or error code and cleaned IDs are normally enough. Never publish account tokens, file keys or original user data.