Home / Product / Protocol services

Connect through standards

Expose supported standard protocols so existing tools can reach Daptin records and files.

Use APIs, feeds, WebSockets, mail, FTP, and scoped DAV-style access where those established interfaces fit the experience.

See what it changes Technical guide ↗

Protocol services in a product

Choose the audienceApplication, feed reader, mail client, or file tool

Use the fitting interfaceAPI, live connection, or established protocol

Reach the same product contextRecords and services stay connected

One backend can meet several kinds of client

01Bring existing tools into the productUse interfaces clients already understand.

02Choose by experienceMatch request/response, live, mail, feed, or file workflows.

03Keep boundaries visibleEvaluate each protocol's exact access and compatibility scope.

Why it matters

Document each protocol’s supported operations and test them with the client tools customers use.

A mobile app needs an API. A dashboard benefits from live events. A reader wants RSS. A mail client speaks IMAP. A publishing tool may use FTP. Forcing them all through a proprietary SDK creates work and lock-in.

Daptin exposes several established interfaces over connected application services. Each one has its own strengths and scope, but they draw from the same wider world of records, accounts, files, certificates, and operations.

The product can therefore meet people in familiar tools while keeping exact behavior and security boundaries documented per protocol.

Teams test required operations against each released protocol implementation before rollout.

Use ordinary HTTP, GraphQL, feeds, WebSockets, and compatible protocol tools.

Match the interface to the job

Choose live delivery for change, mail for communication, or file protocols for content management.

Keep product context central

Route supported standard protocols to the same Daptin records, files, and permission checks.

How it fits

Part of one connected backend.

Protocol services does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Identify

Choose the person, tool, or service that needs access.

Step 2Select

Use the interface that matches its workflow.

Step 3Authorize

Apply the supported identity and access boundary for that path.

Step 4Connect

Read, change, receive, publish, or transfer product information.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Multi-channel product

Serve web and mobile APIs, live dashboards, and public feeds.

Mail-enabled operations

Combine stored messages with application actions and IMAP access.

Content publishing

Use sites, storage, HTTPS, FTP, and scoped DAV clients together.

Connected by design

Let existing tools use familiar interfaces while the application keeps one model and permission system.

These capabilities share the same application context, so each one makes protocol services more useful.

Know the boundary

What Daptin leaves in your hands.

Test each required client operation against the documented protocol implementation. Review each service's supported operations, authentication, TLS, permission reuse, network exposure, and client-specific behavior.

Understand the operating responsibility →

Build from one foundation

Expose the same records and files through each documented protocol endpoint.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities