How does Admaxxer store my credentials?
Ad-platform credentials (Meta tokens, Google refresh tokens, and similar secrets) are encrypted with AES-256-GCM at the application layer before being written to Postgres. The encryption key lives outside the database so a DB-only breach cannot expose tokens.
Admaxxer AI Analytics is a marketing analytics platform for ecom and SaaS teams.
Admaxxer is a DTC analytics platform with built-in Meta + Google ad ops. Given the sensitivity of ad-account access, the first security question most teams raise is: how does Admaxxer store my credentials? The short version is that every token we hold — Meta user tokens, Google refresh tokens, and similar secrets — is encrypted with AES-256-GCM inside the application before it ever reaches the database, using a key that never sits in Postgres.
The short answer
Ad-platform credentials (Meta tokens, Google refresh tokens, and similar secrets) are encrypted with AES-256-GCM at the application layer before being written to Postgres. The encryption key lives outside the database so a DB-only breach cannot expose tokens.
Full answer
The encryption model
Every write path that handles an ad-platform credential runs it through server/crypto.ts, which uses:
- AES-256-GCM — authenticated encryption, so a tampered ciphertext fails to decrypt rather than silently returning garbage.
- A per-record IV (initialization vector) generated fresh at encrypt time.
- An auth tag stored alongside the ciphertext to detect modification.
The plaintext token is never written to disk. Only the encrypted payload, IV, and auth tag land in the ad_platform_connections table.
Where the key lives
The ENCRYPTION_KEY is set as an environment variable on the application server, sourced from a secrets manager (Replit secrets in the managed product; whatever secrets store you configure when self-hosting). It is not stored in Postgres, not checked into the repo, and not exposed to the frontend. An attacker who dumps the database gets ciphertext and no way to decrypt it.
Rotation and expiry
Tokens are rotated proactively:
- Meta long-lived tokens expire ~60 days after issue. A background cron refreshes them inside a rolling window (default 7 days before expiry) so active workspaces never hit an expired token.
- Google refresh tokens do not expire under normal use, but Admaxxer revalidates them on every sync and emails you immediately if Google revokes a token so you can reconnect.
Session and user auth
Application sessions use an HTTP-only, signed cookie backed by Postgres session storage. Passwords are not stored at all — auth is magic-link or OAuth (Google, Apple). Magic-link tokens are single-use, expire in 24 hours, and are invalidated immediately on redemption.
Deletion
When a workspace disconnects an ad platform, the encrypted credential row is soft-deleted and scheduled for hard deletion on the next cleanup pass. Workspace deletion removes all associated credentials within the standard data-retention window.
Related questions
Related Questions
Does Admaxxer have access to my raw Meta token?
Only transiently in application memory when we make API calls on your behalf. The token is encrypted at rest with AES-256-GCM and the encryption key lives outside the database.
Does Admaxxer store passwords?
No. Authentication is magic-link email or OAuth with Google or Apple. No passwords are stored or transmitted.
What happens to my credentials if I delete my workspace?
Encrypted credentials are soft-deleted immediately and hard-deleted in the next cleanup pass, along with any session data tied to that workspace.
Still have questions?
See the full documentation or start a 7-day free trial — no credit card required.
Try Admaxxer Free