Your social accounts stay yours.

Official platform integrations

Dual.am integrations use the official APIs and authorization flows provided by each supported platform. You connect an account by signing in on the platform's own site and approving the permissions there — the login form is theirs, not ours, and your password is never typed into Dual.am.

We request only the permissions publishing actually requires: the ability to post to the Pages, profiles, or channels you selected. We do not request or use permissions to read your inbox, message your contacts, or profile your audience.

Meta operates an App Review process to verify that apps use its APIs and products in approved ways, and TikTok likewise requires apps using its developer tools to go through review.

Telegram is the one exception to OAuth, because Telegram has no OAuth flow for bots: you create a bot in Telegram yourself and paste its bot token into Dual.am. That token belongs to a bot you own — never to your personal Telegram account — and you can revoke it from Telegram at any time.

You can revoke Dual.am's access from inside any platform's own app settings at any time, independently of anything you do in Dual.am.

Encryption

In transit: the entire application is served over HTTPS. Traffic between your browser and Dual.am, and between Dual.am and every platform API, is encrypted in transit.

At rest: OAuth access tokens, refresh tokens, Telegram bot tokens, two-factor secrets, and two-factor recovery codes are stored encrypted using AES-256 with an authenticated encryption scheme, so a modified ciphertext is rejected rather than decrypted. The encryption key lives in the server environment, never in the database and never in our source code.

Account passwords are never stored in any reversible form — they are hashed with bcrypt. Nobody at Dual.am, including us, can read your Dual.am password.

Token handling

• A token is decrypted only at the moment a background job publishes a post you scheduled — not when you browse the app, and not on any page load.
• Tokens are excluded from every API response and are never rendered back into a page, so they cannot be read out of the browser after they are saved.
• Tokens are used for publishing the content you composed, to the destination you chose, at the time you chose. Nothing else.
• Where a platform supports refresh tokens, Dual.am refreshes expiring tokens automatically so publishing never stalls. When a token can no longer be refreshed, the connection is flagged for reauthorization instead of silently failing.
• Disconnecting an account deletes its stored tokens from our database immediately.
• We do not sell platform data, share it with advertisers, or use it to train machine learning models.

Workspace isolation

Every connected account, post, and schedule belongs to exactly one workspace. Isolation is enforced at the database query layer — every query for workspace-owned data is automatically constrained to the workspace you are currently working in, rather than relying on each screen to remember to filter correctly.

This applies between your own workspaces too, not just between different customers. If you run one workspace per client, content and credentials in one client's workspace are not visible from another.

Within a workspace, teammates you invite hold explicit roles, and actions like managing connections, managing members, and transferring ownership are permission-checked on the server for every request — not just hidden in the interface.

Account and data deletion

• Disconnect one account: removing a connection from your Connections page deletes its stored credentials right away.
• Delete your account: you can delete your Dual.am account yourself from your Profile page. Deletion requires re-entering your password, and removes your account along with its associated workspace data.
• Deletion by request: if you would rather we do it, email [email protected] from the address on the account and we will process the deletion.

Deleting your Dual.am account does not delete anything already published to a social network — those posts live on the platform and are managed there.

Infrastructure security

• Dual.am runs on Linux servers with a PostgreSQL database and a Redis queue that are not exposed to the public internet — only the application itself is reachable from outside.
• Secrets — database credentials, platform API keys, the encryption key — are held in the server environment. They are not committed to source control and are not present in the application code.
• Production runs with debug output disabled, so error pages never leak stack traces, queries, or configuration values to visitors.
• Sessions use signed, HTTPS-only cookies, and every state-changing form is protected against cross-site request forgery.
• Incoming billing webhooks are verified by signature before being acted on, so a forged request cannot alter your subscription.
• Payments are handled entirely by Paddle, our merchant of record. Card details are entered on Paddle's infrastructure and never reach Dual.am's servers.
• Dependencies are kept current, and an uptime health check monitors the production application continuously.

Backups

The production database is backed up on a regular automated schedule, and backups are stored separately from the server that produced them, so losing the application server does not mean losing your data. Backups are subject to the same access restrictions as production: only the operators listed under Access control can reach them.

Because your credentials are encrypted before they are written to the database, they remain encrypted inside every backup as well — a backup on its own does not reveal a single usable token.

Access control

Dual.am is run by a small team, which means the list of people who can reach production is short and known by name. Access is granted on a need-to-operate basis and removed when it is no longer needed.

• Administrative and infrastructure accounts used to operate Dual.am are protected with two-factor authentication using Google Authenticator, on top of a password — a stolen password alone is not enough to get in.
• Everyone uses their own named account. There are no shared logins to production systems.
• Nobody browses customer content as a matter of routine. Access to production data happens only when it is required to fix a specific problem or to answer a support request you raised.
• Stored tokens are opaque to us in normal operation: they are never displayed in the admin interface or in the app after they are saved.

Two-factor authentication for your account

You can turn on two-factor authentication for your own Dual.am account from your Profile page. It works with Google Authenticator and any other standard TOTP app — scan the QR code, confirm one code, and every future sign-in asks for a six-digit code as well as your password. You also get one-time recovery codes in case you lose your phone, and you can regenerate them at any time.

If you manage client accounts on Dual.am, turning this on is the single highest-value thing you can do to protect them.

Incident response

If we detect or are told about a security incident, our order of operations is: contain it, assess exactly what was affected, fix the underlying cause, and then tell the people whose data was involved.

• If your data is affected, we will notify you directly by email — with what happened, what was exposed, and what you should do — rather than waiting for you to notice.
• Where an incident could involve connected social accounts, our first containment step is to revoke or rotate the affected credentials, so the safe outcome is that you are asked to reconnect an account.
• We will not quietly downplay an incident. If we get something wrong, the notice will say so.

Reporting a vulnerability

If you believe you have found a security vulnerability in Dual.am, please tell us before you tell anyone else. Email [email protected] (or [email protected]) with enough detail to reproduce the issue — a URL, the steps you took, and what you observed.

• We aim to acknowledge reports within 3 business days.
• We will keep you updated while we investigate, and tell you when it is fixed.
• We will not pursue legal action against researchers who report in good faith, stay within their own test account, avoid accessing or modifying other people's data, and give us a reasonable window to fix the issue before publishing.
• Please do not run automated scanners, load tests, or denial-of-service testing against production.

We do not currently run a paid bug bounty, but we are glad to credit you publicly if you would like that.

Who runs Dual.am

Dual.am is developed and operated by Turn LLC, an Armenian technology company founded by Rafayel Tobelyan.

Turn LLC also operates Turn.am, one of Armenia's biggest service discovery platforms. Dual.am is not a side project of an anonymous team — it is run by a registered company with a public track record and a name attached to it.

For anything else — questions about this page, a data request, or a security concern — email [email protected]. The formal terms are in our Privacy Policy and Terms of Service.