Home / Product / Credentials

Connect services safely

Use outside services without putting their secrets in your product screens.

Store provider keys and account details as permissioned backend records, then let approved storage and integration workflows use them.

See what it changes Technical guide ↗

Credentials in a product

An operator adds a connectionStore the provider key in the backend

A workflow needs the serviceReference the approved credential

Daptin performs the callThe browser never needs the reusable secret

Provider secrets stay behind the product boundary

01Keep secrets out of client codeAvoid shipping provider keys to browsers or mobile apps.

02Share a connection deliberatelyPermission the credential separately from the workflow that uses it.

03Rotate without redesigning the productUpdate the connection record while actions continue to reference it.

Why it matters

A useful integration should not turn a provider key into an application-wide secret.

Cloud storage, external APIs, and mail services often need long-lived credentials. Putting them in frontend code exposes them; copying them into every workflow makes rotation and access review difficult.

Daptin stores credentials as their own permissioned records and encrypts their sensitive values with runtime-managed key material. A cloud store or integration can reference the credential when it performs backend work.

This keeps the product flow simple for the customer while giving operators a visible place to grant, rotate, and remove outside-service access.

Separate the secret from the feature

The action or storage connection describes what to do; the credential supplies approved access.

Control who may refer to it

Treat credentials as protected application data rather than ambient configuration.

Make rotation practical

Replace or revoke a connection without teaching every client a new secret.

How it fits

Part of one connected backend.

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

Step 1Store

Create the provider credential through a protected path.

Step 2Protect

Encrypt sensitive values and restrict who may reference the record.

Step 3Connect

Attach it to a cloud store, integration, or other backend service.

Step 4Execute

Use it only when an approved backend workflow needs the provider.

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.

Cloud file storage

Keep object-storage credentials away from upload and download clients.

Business-system integration

Call a CRM, support tool, or provider without exposing its key.

Service-specific mail

Use an approved delivery provider inside a backend mail action.

Connected by design

Build the next part without starting over.

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

Know the boundary

What Daptin leaves in your hands.

Encryption depends on the strength and handling of your runtime key material. You remain responsible for secret creation, least privilege, rotation, revocation, backups, audit access, and the security of the provider account itself.

Understand the operating responsibility →

Build from one foundation

Make credentials part of the product—not another disconnected service.

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

Get Daptin Explore all capabilities