Home / Product / Credentials

Connect services safely

Call providers from authorized backend actions that resolve protected credentials.

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 callKeep reusable provider credentials in protected backend records.

Provider secrets stay behind the product boundary

01Keep secrets out of client codeResolve provider keys on the server after checking the caller’s permission.

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

03Rotate a stored provider credential once and let every authorized action use the replacement.Update the connection record while actions continue to reference it.

Why it matters

Store each provider key as a protected credential and resolve it only for authorized actions.

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

Store credentials as protected application records with explicit ownership and access rules.

Make rotation practical

Replace or revoke one stored connection and let authorized clients keep the same product action.

Keep service access behind the product

Connect personal and company service accounts safely.

A person can approve their own account, while a company account can use protected sign-in details supplied by the service. Daptin checks ownership before the task begins.

Diagram showing personal customer approval and protected company sign-in details converging on an ownership check before a service task runs. — **Choose the right connection for each service task**Use customer approval for a personal account or protected company sign-in details for a shared business connection.Open diagram for full-size view

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 CRM, support, and provider APIs from backend actions that resolve stored credentials.

Service-specific mail

Use an approved delivery provider inside a backend mail action.

Connected by design

Connect CRM, support, storage, and provider calls while keeping reusable credentials on the server.

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

Keep provider secrets on the backend and resolve them only for authorized calls.

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

Get Daptin Explore all capabilities