Docs

Admin configuration (super-admin)

This guide is for platform operators who use the /admin area: managing tenants (clients), OAuth apps for social networks, plans, payments, email, languages, CMS pages, and system settings.

Accessing the admin panel

  • Admin UI routes live under /admin (e.g. http://localhost:5173/admin/login in development).
  • Admin authentication is separate from tenant user auth; use credentials created for admin users in your deployment.

Permissions inside admin are role-based (e.g. dashboard, tenants, plans, social platforms). If you lack permission for a screen, you may be redirected to a forbidden page.

Clients (tenants)

Clients lists tenant accounts (your customers). From here you typically:

  • Create or manage organizations using the product
  • Tie each client to subscriptions and plans
  • Support onboarding and troubleshooting

Multi-tenant data isolation is enforced in the API using tenant/client identifiers.

Social platforms (OAuth)

Social Platform is where each network is enabled and configured with developer-app credentials (client ID, client secret, and provider-specific fields).

For step-by-step instructions (Meta Developer Console, redirect URIs, permissions/scopes per network, and what to paste into SocialMine), see the dedicated guide: Social platform configuration.

Why this matters

End users connect accounts via OAuth. The backend:

  • Builds authorization URLs for Facebook, Instagram, LinkedIn, X, TikTok, Threads, etc.
  • Handles the callback on the API, exchanges the code for tokens, encrypts and stores them, and associates ConnectedSocialAccount records with the user/tenant.

Environment: API_PUBLIC_URL

Set API_PUBLIC_URL in the root .env to the public origin of your API without the /api path, for example:

  • Local: http://localhost:3000
  • Production: https://api.yourdomain.com

OAuth redirect URIs registered in Meta, LinkedIn, X, TikTok, or Threads must match the callback URLs your deployment uses. If you change API_PUBLIC_URL or domain, update every provider console accordingly.

The marketing site and client API page may display the API endpoint for integrators; keep documentation in sync when you change URLs.

Per-platform notes

  • Facebook / Instagram: Usually one Meta app; Instagram uses Facebook login with specific scopes. Ensure instagram_content_publish and related scopes match the code’s expectations if you change them.
  • X: OAuth 2.0 with PKCE is supported in the connect flow.
  • LinkedIn: OpenID-style scopes for profile and posting.
  • TikTok / Threads: Follow each provider’s current app review and scope requirements.

If a platform is disabled or missing secrets in admin, users will see errors when connecting or publishing.

Plans and subscriptions

  • Plans — define tiers (limits, features, pricing as modeled in your schema).
  • Subscriptions — view or manage tenant subscriptions and status.
  • Payment gateways — configure Stripe (or other supported gateways) so checkout and webhooks work.

Webhooks and secrets for payments belong in environment variables and admin gateway configuration as documented in code and .env.example.

Email

Email settings configure SMTP or provider details used for transactional mail (verification, password reset, notifications). If SMTP is missing, behavior may fall back to a non-production or logging mode depending on implementation.

Currencies and languages

  • Currencies — supported currencies for billing display and charges.
  • Languages — i18n content and available locales for the tenant-facing app where applicable.

Landing pages / CMS

Landing Pages ties into the CMS module for marketing pages (home, pricing, legal). Content may be edited per deployment strategy (database-backed pages).

Roles and admins

  • Roles Permissions — define which admin screens and actions each role can access.
  • Admins — manage staff accounts for the /admin panel.

System settings

Settings (admin) typically includes SaaS branding (logos, names), feature flags, and global defaults. Tenant-facing branding may also be overridden per client in tenant settings where the product allows it.

Security practices

  • Restrict /admin to trusted networks or VPN in production if possible.
  • Use strong secrets in .env; rotate JWT and encryption keys according to your policy.
  • Never commit .env files; use CI/CD secrets stores in production.

For database backups, SSL, and infrastructure hardening, follow your organization’s standards in addition to the Setup checklist.

Last Updated: