Why use a social media post API?
All social scheduling tools do the publishing for you. You authorise an account, add a post to the queue and, at the correct time, it goes out on whichever networks you like. But none of them address the empty box at the beginning of that flow. Someone still has to write the post.
If you're building a social media product, an agency dashboard, or an AI agent that manages accounts, that's where the gap falls on you. You can hook up a language model and get text out, but raw model output has two problems here. It reads like every other scheduled post in the feed, and it increasingly gets flagged as machine-written by both readers and platform classifiers.
The SpeedContent social media post API fills that space in a single call. Provide a topic and a platform and it returns a finished post written in the style of that network, rewritten so it doesn't sound like a bot produced it, scored by an AI detector, and illustrated with a generated image if you want one.
One call, seven platforms
Generation is multi-stage, so the API is asynchronous. You submit a job, get an ID back immediately, and poll until it finishes. A typical post takes between 20 and 90 seconds depending on length, quantity, and whether you asked for an image.
curl -X POST https://generatecontentwithaiservice-g5zrtckfda-ue.a.run.app/api/v1/social/generate \
-H "Authorization: Bearer sc_your_api_key" \
-H "Content-Type: application/json" \
-d '{
"topic": "Why small teams ship faster than big ones",
"platform": "linkedin",
"tone": "professional"
}'
Response:
{
"job_id": "68d4f1a2c9b17e0012ab34cd",
"status": "queued",
"poll_url": "/api/v1/social/jobs/68d4f1a2c9b17e0012ab34cd",
"estimated_seconds": 23,
"estimated_credits": 30
}
Poll the poll_url until status reads completed, and the finished post arrives with its hashtags, image URL, and detection score.
Every post is humanized before you see it
What makes this different from wrapping a language model yourself is everything that happens once the first draft exists — and the humanization pass is the heart of it.
Raw model output has a signature. It reaches for the same connectives, settles into a uniform sentence length, and leans on filler like "in today's fast-paced world" and "it's worth noting." Readers notice it even when they can't name it, and classifiers are trained on exactly those patterns.
Every post generated through this API is passed through the same engine behind the AI humanizer API. It restructures the prose rather than swapping synonyms: sentence length and rhythm are varied to produce the burstiness human writing has, filler phrasing is stripped, and overall perplexity is shifted out of the band detectors look for. Your topic, your keywords, and your brand voice survive intact.
This is not an optional extra you call separately afterwards. It runs on every post, on every platform, before the result is ever returned to you.
The result is then scored by an AI detector on a scale where zero reads as human. Platform-appropriate emoji are injected, and suppressed entirely on LinkedIn and YouTube where they read as unprofessional. If the score comes back too high, the post is humanized and scored again automatically.
Each of those steps is a separate service call. Building the same chain yourself means integrating a language model, a humanizing service, a detection service, and an image generator, then coordinating retries between them. Here it's one endpoint.
Why the detection score matters
The detection score is the part worth watching, because it's the only step that tells you something you couldn't otherwise know.
Anyone can attach a prompt to a model. What you can't easily discover is whether the text you're about to publish will read as machine-written to someone else's classifier. The score comes back attached to the post, so your application can decide before anything goes out: publish automatically below a threshold, route higher-scoring posts to a human, or simply show the number to your user and let them judge.
When a post hasn't been scored, the field comes back empty rather than zero. That distinction is bigger than it first appears. Zero means scored and reads as human. Empty means nothing measured it. Returning zero for both would hand you a confident-looking result for a check that never ran.
Platform-native, not one prompt reskinned
Seven platforms are supported, each with its own writing guide and default length.
| Platform | Default length | Emoji | Written as |
|---|---|---|---|
| 100 words | None | Insight-led, counter-intuitive hook, reflective close | |
| 75 words | Heavy | Conversational, story-led, strong call to action | |
| 50 words | Heavy | Caption-style, visual-first | |
| X (Twitter) | 40 words | Moderate | One quotable idea, built to be shared |
| 75 words | Moderate | Descriptive, keyword-aware, inspirational | |
| YouTube | 150 words | None | Description-style, longer form |
| TikTok | 50 words | Heavy | Hook-first, trend-aware, casual |
These aren't length settings on one shared prompt. They're genuinely different instructions producing genuinely different copy. You can override the word count per request, from 10 to 500, and request up to 10 variations in a single call.
Credits and what you pay for
Pricing is credit-based and you only pay for the steps you use. A post up to 200 words costs 20 credits, with one extra credit per additional 10 words. An image adds 10 credits and AI detection adds 8. The total is multiplied by the number of variations you asked for.
Detection defaults to automatic, meaning it only runs on posts of 150 words or more. Short posts score unreliably, and the detector charges a flat rate regardless of length, so running it on a 40-word post would cost about as much as writing the post and tell you very little. You can force it on or off per request.
Credits are reserved when the job is accepted and refunded in full if generation fails. You're never charged for a post you didn't receive.
For AI agents: the MCP server
The same capability is available to AI agents through a remote server listed in the official Model Context Protocol registry. There's nothing to install.
{
"mcpServers": {
"speedcontent-social": {
"url": "https://speedcontent.online/mcp",
"headers": { "X-API-Key": "sc_your_api_key" }
}
}
}
An agent in Claude, Cursor, or any MCP-compatible client gets three tools: one to start a post, one to collect it, and one to list the supported platforms. This complements the publishing tools agents already use — an agent can draft with SpeedContent and publish through whichever scheduling API it's already connected to, without the user leaving the conversation.
What you can build
The most direct use is adding generation to a product that already publishes. If your users schedule posts, they're writing them somewhere else first, usually a chat window they copy out of. Moving that step inside your product removes the copy-paste and gives you a feature your competitors don't have.
Agencies run the same workflow at volume across many client accounts, where brand voice parameters keep each client sounding like themselves. Content teams repurpose a single blog post into a week of platform-specific copy.
Start generating
Create an API key from the API Keys page in the SpeedContent dashboard. Free credits on signup are enough to generate several posts end to end before you commit to anything.