> Source: https://www.trackmedia.app/blog/enterprise-social-media-management · Last updated: 2026-10-06 # Enterprise social media management checklist An enterprise social media management checklist: questions on roles, audit trails, SSO, API keys, webhooks, token storage and data deletion to ask any vendor. *Guides · Published 2026-10-06* Enterprise social media management comes down to a short list of questions you put to any vendor before you connect your brand accounts: who can do what, what is logged, how people sign in, how the API is limited, how tokens are stored and what happens to your data when you leave. This guide lists those questions, explains why each one matters, and answers them for TrackMedia from its own code, including the answers that are "not there". There is no standard definition of "enterprise" here. We use it to mean a larger organization with several teams, a security review and a procurement process. If that is you, the checklist below is meant to be pasted into your vendor questionnaire. ![Status table of nine enterprise requirements in TrackMedia: roles, scoped API keys, approval policy, signed webhooks and token encryption are present; audit trail and the key IP allowlist and daily cap are partial; SSO, SAML and SCIM were not found in the code, and a human approval workflow is not in the app.](https://www.trackmedia.app/assets/img/blog/enterprise-social-media-management-fig1.svg) *Where TrackMedia stands on each requirement, based on a review of its code on October 6, 2026.* ## Who can do what: roles and access Ask the vendor how access is divided between people, brands and clients, and whether a person with the lowest role can ever publish or change a connection. Shared logins are the failure you are trying to avoid, because they erase who acted. Our guide to [managing multiple social media accounts](https://www.trackmedia.app/blog/how-to-manage-multiple-social-media-accounts) covers the least-access habit in more detail. In TrackMedia, an organization contains workspaces, one per brand, client or project, with a switcher in the app. Inside a workspace there are four roles: Owner, Admin, Editor and Viewer. Editors can write, schedule and publish but cannot change connected accounts or API keys, and Viewers are read-only. At the organization level the roles are Owner, Admin and Member. Not in the code: custom roles, or per-network permissions such as "this person may post to LinkedIn but not X". Roles apply to a workspace as a whole. ## How are approvals and API keys controlled? Ask whether a draft can be forced through a human check, and whether automated callers get narrower rights than people. TrackMedia has no built-in approval gate for people. Approvals are not built yet, so review is a team habit: a writer leaves a post as a draft and a reviewer schedules it. For automated callers there is a real control. Each API key is created with a name, one or more of 13 scopes (for example `posts:read` or `posts:write`), an optional expiry date (set through the API; the dashboard form does not show one) and an approval policy. The policy is one of `auto` (publish without asking), `require_human` (the key can create posts but a person must publish them) or `draft_only` (the default). With either of the last two, a request to publish still produces a draft, and a direct publish call is refused. The key itself is shown once and stored as a SHA-256 hash with a short display prefix, and a key cannot create another key. Revoking a key takes effect immediately, and the row is kept with a revoked timestamp. The API accepts a daily post cap and an IP allowlist when a key is created (the dashboard form shows only the daily cap). We found those values stored but found no code that enforces either, so do not rely on them until the vendor confirms it. ## Is there an audit trail? Ask what events are recorded, who or what is recorded as the actor, how long records are kept, whether records can be exported, and whether a failed write can be silently lost. An audit trail you cannot read does not help during an incident. TrackMedia's code has an append-only audit table. Each row stores the organization, workspace, actor type (user, API key or system), actor id, an action name, a target, optional metadata, an IP address field and a timestamp. The code we read never fills the IP address field, so expect it to be empty. The action names we found being written are `account.connect_started`, `account.connect_returned`, `account.connected`, `account.disconnected`, `api_key.created`, `api_key.revoked`, `post.publish_requested`, `workspace.created` and `workspace.deleted`. Three limits matter. We found no screen or API endpoint that reads the table, so there is nothing to browse or export today. A write failure is deliberately swallowed so it never breaks a request, which means a row can be missing. And member role changes are not among the events we found written. Treat it as a record kept for investigation by the vendor, not as a compliance report you can pull yourself. ## Can people sign in through your identity provider? Ask whether the vendor supports SAML or OIDC single sign-on, SCIM provisioning and enforced multi-factor authentication, and on which plans. These decide whether offboarding someone in your directory also removes their access. We cannot confirm that TrackMedia offers this. Sign-in runs through Clerk, and accounts are created in the app the first time a person signs in. We found no SAML, SCIM or organization-level SSO configuration in TrackMedia's code, and no enforced-MFA setting. Clerk has dashboard settings we could not see, so do not assume either way: ask the vendor to state in writing what is supported. ## How are API limits and webhooks handled? For an API, ask what the rate limits are, what a client sees when it hits one, and how the vendor limits abuse. OWASP's [API Security Top 10 (2023)](https://api-security.owasp.org/editions/2023/en/0x11-t10/) lists "Unrestricted Resource Consumption" as API4 and "Broken Function Level Authorization" as API5, and both map directly onto limits and scopes. Platform limits are a separate layer on top: every network sets its own, as our piece on [X management tools](https://www.trackmedia.app/blog/x-twitter-management-tools) explains for the X API. TrackMedia's limiter is set in code to 300 requests per minute per API key, or per IP address when there is no key, and 30 per minute on routes under `/v1/auth/`, which today is only `/v1/auth/me`. Sign-in itself runs through Clerk. Exceeding it returns HTTP 429 with a retry message. These are defaults in the configuration and the store is in-process, so ask what the production values are before you design a high-volume integration. For webhooks, ask whether payloads are signed, how a retry works and how to dedupe. TrackMedia signs each delivery with an `X-TrackMedia-Signature` header, `sha256=` followed by an HMAC-SHA256 of the exact request body, keyed by the endpoint's secret. It also sends `x-trackmedia-event`, `x-trackmedia-delivery` (a delivery id you can use to ignore duplicates) and `x-trackmedia-timestamp`. The timestamp is not part of the signed bytes, so a strict replay check is your job. A response of 429 or 5xx, or a network error, is retried with exponential backoff and jitter, up to eight attempts in total. The delays start near 30 seconds and double each time, so by our arithmetic from the code all eight attempts fall within about an hour, not a day. After the last attempt the delivery is marked dead. Other 4xx responses are not retried. There are 14 event types, including `post.published`, `post.failed`, `account.token_expiring` (seven days before expiry) and `account.needs_reconnect`. ## How are social account tokens stored? This is the center of most security questionnaires, because a leaked social token lets someone post as your brand. Ask how tokens are encrypted, who can decrypt them, whether keys are separated per customer, whether they appear in logs, and whether keys can be rotated. TrackMedia keeps all decryption in one module, `packages/db/src/vault`. Tokens and webhook secrets are encrypted with AES-256-GCM. Each stored secret gets its own random data key, and that key is wrapped, also with AES-256-GCM, under a key derived from a master key and the organization id, so a wrapped key from one organization does not unwrap under another. Each ciphertext is bound to its database row, so copying an encrypted blob to another account row fails to decrypt. Decrypted values live in memory for one call, and the API's logger replaces fields such as `token`, `accessToken`, `refreshToken`, `secret` and `credentials` with [Redacted]. Two honest limits. The repository contains only the provider that wraps keys with a master key from an environment variable; the interface for a cloud KMS exists, but we found no implementation, so ask where the master key lives in production. And data-key rotation is a documented to-do in the code, not a working job. ## What happens to your data when you leave? Ask for the deletion path in writing: what is removed, how fast, what is retained and for how long, including backups. TrackMedia's data deletion page on trackmedia.app (last updated September 20, 2026) lists three routes: disconnect one social account, delete the whole account, or email a request. The page says deletions made in the product take effect immediately, email requests are actioned within 30 days, and encrypted backups are purged on their normal rotation within 90 days. It also says posts already published stay on the social platform and must be deleted there, and that minimal records such as invoices may be kept where law requires. One point to confirm with any vendor, TrackMedia included: disconnecting an account inside the tool is not the same as removing the app in the network's own settings. The deletion page says Disconnect revokes and deletes the access token. In the code we read, Disconnect deletes TrackMedia's stored copy and asks the platform to revoke the token only where a connector has a revoke call, on a best-effort basis, and only the TikTok connector has one. For the other networks, also remove the app in the network's own settings; the deletion page lists where to do that on Facebook, Instagram, Threads, TikTok, LinkedIn and X. ## What else belongs in the security questionnaire? These topics are outside what a code review can answer, so TrackMedia makes no claim about them in this article. Put them on your list anyway: - **Certifications and audits.** Which independent reports exist, and can you read them under NDA. - **Hosting and data location.** Where data is stored, and which subprocessors touch it. - **Incident response.** How and how fast customers are told about a breach. - **Uptime and support.** Written commitments, if any, and who answers. Also ask the shared-login question for the networks themselves. Instagram Help Center pages on shared logins and automation are summarized in our post on [the automated behavior warning](https://www.trackmedia.app/blog/instagram-we-suspect-automated-behavior). When you are ready to test TrackMedia against your list, you can [start free at go.trackmedia.app/signup](https://go.trackmedia.app/signup). ## How we checked this Read on October 6, 2026: - OWASP, [OWASP Top 10 API Security Risks 2023](https://api-security.owasp.org/editions/2023/en/0x11-t10/): the names of API4 and API5, opened in a browser tab. - TrackMedia's own repository: API key schema, tenant and role types, posts service, audit module, rate limiter, webhook delivery service and event list, token vault and key provider, the API logger's redaction list, and the account disconnect code. These are code reads, not live tests of production. - TrackMedia's Data Deletion page, https://www.trackmedia.app/data-deletion (last updated September 20, 2026): the three routes, the timeframes and the platform revoke table. We could not verify: production rate-limit values, which key provider production uses, whether the daily cap and IP allowlist are enforced anywhere we did not look, whether any audit screen exists in a build we did not read, what Clerk's dashboard settings allow (SSO, MFA), any certification or hosting detail, and whether the data deletion page's wording about revoking tokens holds for networks whose connectors have no revoke call. No platform help pages are cited, so no platform behavior is claimed beyond what TrackMedia's own code does.