What SMM Agent's Public Materials Commit To Before You Connect an Account

The posting docs specify drafts by default and a separate publish call. A September 28, 2026 blog post describes one liked-post lane that stays off until two variables are set.

*Image: Social Media App Icons On The Screen of A Smartphone by mikemacmarketing, licensed under CC BY 2.0.*

SMM Agent's posting documentation tells agents to create drafts first and treats publishing as a separate, explicit call. The docs put both rules under Safe default, alongside four access constraints: bearer keys are workspace scoped, Read & Write permission is required for posting, schedule times must be in the future, and connected platform targets stay inside the current workspace.

The homepage frames the product as an operating layer for social posts, replies, approvals, and platform-specific distribution. The public record behind that framing includes the homepage, posting docs, terms of service, privacy policy, blog index, and a September 28, 2026 blog post that reviews several of the same surfaces.

All of it is first-party. That blog post says the pages it reviewed supply documented material and no independent test results, and that none of the calls in its posting-contract section had been executed. No API call was executed for this article, so what follows is specification, contract language, and policy from the product's own pages; whether a workspace behaves that way is a separate question.

The draft-first contract

Access starts with a key. The docs describe an App Access key created in dashboard settings with Read & Write permission, stored in the agent runtime as SMM_AGENT_API_KEY, and scoped to a workspace. A post is a POST to https://smmagent.app/api/posts. The payload accepts content, required unless media is supplied; an optional internal title; contentType set to text, image, or video; and intent, which defaults to draft. Optional fields cover platformIds, a public mediaUrl or mediaUrls, and platformOverrides for per-platform caption, format, first comment, and related fields.

Publishing is a separate endpoint, POST /api/posts/{id}/publish, which runs the connected platform pipeline for the saved post targets and should stay behind explicit user approval. The docs also publish a drop-in agent prompt with matching defaults: create drafts unless the user explicitly asks to schedule or publish, use intent: "schedule" only with a future ISO scheduledAt, publish only after explicit approval, and never print the API key.

The captured docs describe no publish intent on the draft endpoint, so an agent working from them reaches publishing through the second call. Whether the API enforces that separation is a behavior to check in a workspace.

Scheduling and targets

Scheduling uses intent: "schedule" with a future ISO timestamp in scheduledAt.

A past timestamp is the edge case the September 28 blog post's trial plan expects the product to refuse. The docs state the requirement; the captured pages do not show the error path, so refusal is a behavior to confirm.

Workspace scoping determines what a key can reach. Under the docs a bearer key reaches one workspace, so a key created for a client workspace reaches that workspace's connected accounts and nothing in other workspaces. Target IDs come from the workspace's own connection list, and a platform ID from another workspace has no documented meaning.

The lane with no per-post gate

The September 28 blog post reports that the repository README documents one lane with no per-post human review or approval once its worker is enabled: an X liked-post queue. A like from the account holder feeds the queue; liked posts become scheduled post rows in hourly slots between 8 AM and 8 PM, deduplicated with an x-like:<tweetId> key and published later by the normal scheduler. The import worker is disabled by default and runs only when both X_LIKES_AUTOPUBLISH_ENABLED=true and X_LIKES_AUTOPUBLISH_MODE=publish are set.

Enabling both removes the per-post review step for that lane, so a like can become a scheduled post without a human approving that specific post. The same account of the README adds that additional public schedules require operator approval, that Medium mutation and scheduling are conditioned on approval plus visible UI proof, and that comment and DM surfaces carry stricter safeguards, some of them paused.

The lane appears in a secondhand description of a README that was not captured for this article, and it was not observed in operation. Its default state is off, so enabling it takes a deliberate configuration change.

What the terms place on the account holder

The terms of service took effect April 21, 2026, and cover smmagent.app, clawposter.app, a third domain during a migration window, and related dashboards, APIs, automations, integrations, and services.

AI-generated content may be inaccurate, incomplete, duplicative, delayed, offensive, infringing, noncompliant, or unsuitable. Users are responsible for reviewing and approving output before use where review controls are available. The contract does not guarantee that output is original, lawful, platform-safe, factual, or fit for a campaign, and it says users should not rely on the service for legal, financial, medical, safety, crisis, political, employment, or regulated-industry advice.

Platform APIs can fail, revoke access, change scopes, reject posts, throttle requests, remove content, or return incomplete data, and SMM Agent is not responsible for platform decisions or third-party outages. Features may not work until extra platform review, permissions, business verification, or user action requirements are satisfied, so a blocked feature can be an availability issue rather than a product failure. The terms allow features to be changed, suspended, limited, or discontinued at any time, including when platform APIs, rate limits, account permissions, or provider policies change.

It disclaims warranties that posts will publish successfully, schedules will run at an exact time, integrations will remain available, or generated content will meet expectations. Total liability is capped at the amount paid in the three months before the claim, or 100 dollars if nothing was paid. New York law governs unless applicable law requires otherwise, and an informal dispute contact step comes before a claim.

Users must connect only accounts they own or are authorized to manage, answer for activity under their account, workspace, API keys, connected accounts, and team members, and defend and indemnify the service and its operator against claims arising from their content, connected accounts, campaigns, instructions, breach of the terms, violation of law or platform rules, or infringement of third-party rights.

What the service holds

The privacy policy describes collection from an account and a connected workspace: account information; workspace content such as drafts, scheduled posts, media URLs, publishing targets, comments, replies, direct messages where platform APIs allow, generated outputs, support tickets, logs, and configuration; platform identifiers, profile details, handles, tokens, refresh tokens, scopes, pages, channels, post IDs, reply IDs, URLs, and publishing or inbox status; and technical data such as IP address, browser and device details, request metadata, cookies, session data, error logs, audit logs, pipeline runs, and security events.

Connecting an account can bring tokens and scopes into the service, where the policy says they are used to authenticate, publish, read permitted inbox surfaces, refresh tokens, and show operational status. It states that SMM Agent does not sell personal information or knowingly share it for cross-context behavioral advertising. It shares information with service providers that host, secure, authenticate, email, observe, analyze, support, and operate the service, and with social platforms when a user connects accounts or asks the service to publish, read permitted inbox content, post replies, refresh account data, or perform another platform action.

The policy says inputs sent to AI systems may include prompts, selected workspace context, content, post text, reply candidates, article text, and related operational metadata, and it names AI providers and observability tools among the services used to generate drafts and debug model behavior. The policy says prompts are designed to avoid sending secrets, raw credentials, access tokens, cookies, or unnecessary personal information; that states an intent rather than an audited result, and the policy adds that no service can guarantee perfect security and that users must keep account credentials, connected platform access, and workspace permissions secure.

Data is retained as long as needed to provide the service, comply with legal obligations, resolve disputes, enforce agreements, maintain security, and preserve operational history, and some records may remain in backups, logs, legal records, security records, or platform records the service does not control. Users can request access, correction, deletion, or export by contacting the address in the policy, and the policy lists location-dependent rights to know, delete, correct, limit certain uses of sensitive information, opt out of sale or sharing, and appeal a decision.

What the public record does not settle

The September 28 blog post says no third-party tests or independent assessments of the product appear among the pages it reviewed, which it describes as the product's pages plus the waitlist pages at clawposter.app and smmclaw.app.

The homepage says it does not fabricate reviews or buy ratings and that client reviews will be published as they arrive, with consent, tied to the campaigns they came from. No client reviews appear in the captured homepage excerpt, so the absence is scoped to that excerpt.

The platform count is unresolved. The blog post reports that clawposter.app states sixteen platforms, while the repository registers eleven named provider integrations (X/Bird, LinkedIn, Instagram, Facebook, Threads, TikTok, Bluesky, Mastodon, YouTube, Pinterest, and Google Business), plus Late and Zernio where configured. Neither figure establishes which accounts a workspace can connect.

The autonomy emphasis is unresolved. The April 2026 blog entries describe unattended posting, while the homepage describes replies with a visible human approval step and the repository documents the liked-post worker as disabled by default with an explicit publish mode. The September 28 blog post says no observed behavior reconciles the difference.

The blog index runs from April 9 to October 14, 2026. The April 17 and April 18 entries use ClawPoster branding, and the April 18 entry describes unattended posting; the terms and privacy policy cover both clawposter.app and smmagent.app, so those entries belong to an earlier brand of the same service.

A first trial that produces your own evidence

The September 28 blog post proposes a bounded first trial. The checks below follow that plan and the posting docs. None of these checks was run for this article.

• Key scope. Create an App Access key with Read & Write permission, store it as SMM_AGENT_API_KEY, and confirm posting requires it and keeps targets inside the workspace.
• Draft default. Create a post through POST https://smmagent.app/api/posts and confirm it lands as a draft that reaches no connected platform.
• Scheduling. Queue a post with intent: "schedule" and a future ISO scheduledAt, confirm it appears as a scheduled item with nothing published, then send a past timestamp as a negative check.
• Explicit publish. Publish the draft through POST /api/posts/{id}/publish and inspect the approval record behind it. If the workspace exposes approval modes, set one that requires review and confirm the publish path respects it; those modes come from the blog post's account of the README, so confirm the surface exists first.
• Workspace targets. Record which providers the workspace can connect, and confirm platform targets stay inside it.
• Liked-post lane, if used. Confirm the worker stays off until both X_LIKES_AUTOPUBLISH_ENABLED=true and X_LIKES_AUTOPUBLISH_MODE=publish are set, and confirm the queue deduplicates likes through the x-like:<tweetId> key.

A single session will not settle per-platform delivery at volume, the quality of reply review under real traffic, or the depth of audit history over months; the blog post notes those answers build with repeated use. Record each result, including blocked ones, since a blocked check can mean a platform requirement described in the terms has not been met.

After the session you have evidence about the draft and publish gate. The liked-post lane remains a separate policy choice, because the public record describes it as publishing without per-post review once its worker is enabled, and the terms assign responsibility for publication choices to the account holder.