FAQ

Short, factual answers about what Pharlo is and how it behaves. For deeper detail, follow the linked canonical pages.

What is Pharlo?

Pharlo is a content-posting service that publishes, schedules, and tracks social media content on a user's behalf. It exposes the same backend through two surfaces: an MCP server for AI agents and a REST API for developers. See the Overview and Architecture & Security.

Is Pharlo an MCP server?

Yes. Pharlo runs a remote MCP server over Streamable HTTP at https://pharlo.io/_mcp, exposing 21 tools (assignments, connections, platforms, stats, webhooks). Authentication is OAuth 2.0 (Bearer token). See the MCP overview and the tools reference.

Is Pharlo also a REST API?

Yes. The same capabilities are available as a REST API under https://pharlo.io/api/v1, authenticated with an API key (ds_live_...). The contract is published as OpenAPI 3.0 (opens in a new tab).

Which platforms are live?

YouTube and Facebook are the only platforms live and publishable today. Other platforms may appear in discovery responses but do not accept publishing. Always confirm with get_platform_capabilities. See the Roadmap.

Is TikTok live?

No. TikTok is Planned, not live — it is not publishable through the MCP or REST surface today. Instagram is also Planned; Twitter / X is Exploring. Only YouTube and Facebook are live.

How does OAuth work?

For the MCP server, Pharlo uses OAuth 2.0 with PKCE. The MCP client opens Pharlo's authorization URL, the user grants access, and the client receives a Bearer token used on every MCP request. For connecting a channel (e.g. a YouTube account), Pharlo issues a short-lived OAuth ticket (valid 15 minutes) that the user completes in the browser. See the setup guide and connect a channel.

Do users need their own platform API keys?

No. Users do not supply YouTube or Facebook API keys. They authorize their channels to Pharlo via OAuth, and Pharlo manages the platform tokens server-side. The only credential a user manages is their Pharlo auth (OAuth for MCP, or a REST API key).

How does billing work?

Pharlo is credit-based. Each publishing or stats operation consumes credits from the workspace's credit pool. Operations performed through the MCP surface carry a 20% credit surcharge over the equivalent REST call. If a workspace runs out of credits or hits a spending limit, the operation is rejected with an HTTP 402 error. See error handling.

What are credits?

Credits are Pharlo's unit of metered usage. Tool/endpoint costs are published per tool in the MCP tools catalog (opens in a new tab). When credits are insufficient, Pharlo returns the machine-readable code insufficient_credits (HTTP 402); when a configured spending cap is reached, it returns user_spending_limit_exceeded (HTTP 402).

What happens if publishing fails?

A failed assignment moves to a failed state with an error reason. The work is not silently dropped — the agent should read the assignment status, surface the reason, and either fix the input or retry. See retry a failed assignment and the error catalog (opens in a new tab).

How do retries work?

Retries are explicit. Call retry_assignment (or the equivalent REST endpoint) on a failed assignment; processing is handled asynchronously via the queue. Do not blindly re-create assignments — retry the existing one to avoid duplicate publishing.

How are webhooks signed?

Every webhook delivery is signed with HMAC-SHA256 over the raw JSON body, using your webhook secret. The signature is sent in the X-Webhook-Signature-256 header as sha256=<hex>. Verify it with a constant-time comparison before trusting the payload. See the verifier examples in Examples and webhook debugging.

Which MCP clients are supported?

Any MCP client that supports remote Streamable HTTP with OAuth 2.0. Claude is tested. Cursor, Windsurf, ChatGPT, and n8n are supported but not yet independently verified. See the compatibility matrix and per-client setup guides.

Is Pharlo self-hosted or remote?

Remote and hosted. Pharlo is a managed service at pharlo.io; there is no self-hosted deployment. You connect to the hosted MCP endpoint or REST API — you do not run your own Pharlo instance.

Is Pharlo open-source?

The core service is not open-source. Example configurations, REST snippets, webhook verifiers, and n8n templates are published for reuse (see Examples), but the backend itself is closed.

Does Pharlo create content?

No. Pharlo does not generate posts, captions, or media. It publishes, schedules, and tracks content that you (or your agent) provide. Content creation is the caller's responsibility.

How is Pharlo different from a social media scheduler?

Traditional schedulers are built for humans clicking a UI. Pharlo is built for programmatic and agent use: a typed MCP tool surface, a REST API, machine-readable discovery (catalog (opens in a new tab), OpenAPI (opens in a new tab)), signed webhooks, and credit-based metering — so agents can publish and verify delivery without a UI.

How is Pharlo different from direct platform APIs?

Direct platform APIs each have their own auth, schemas, rate limits, and quirks. Pharlo gives one consistent surface across platforms, manages OAuth tokens for connected channels server-side, normalizes publishing and stats, and emits signed webhooks — so an agent integrates once instead of per platform.

Roadmap Brand Assets

FAQ