DEV Community: Eugeniya Ivanova

I tried to build an Apple Shortcut from code. Apple said no, four times.

Eugeniya Ivanova — Mon, 27 Jul 2026 10:32:16 +0000

We have a REST API. Apple has Shortcuts, an automation app that can send HTTP requests. Wiring one to the other looked like a free win: "Hey Siri, publish this" → POST to our API → done. No backend, no OAuth, no app to install.

It works. It's on my phone. What I couldn't do — and this is where it got interesting — was build, edit, version, and ship that shortcut from code. Here are the walls I hit, with the exact errors, so you can decide whether to spend an evening the way I spent mine.

What works

The shortcut itself is trivial, three steps:

Ask for Input (text) → "What are we posting?"
Get Contents of URL → POST to https://api.publora.com/api/v1/create-post, header x-publora-key: <key>
Request body (JSON): content from step 1, platforms as an array with one connection ID

Run it, Siri asks, you dictate, the post goes out. Here's the curl equivalent, to show how little logic there is:

curl -X POST https://api.publora.com/api/v1/create-post \
  -H "x-publora-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content":"Shipped from Siri","platforms":["linkedin-ABC123"]}'

Leave out scheduledTime and the post is created as a draft, which is what you want while testing: nothing goes to a live audience.

Building it on the phone took about forty minutes, most of that spent hunting for the right actions in a localized UI. Building it from code took forever. Here's why.

Wall 1: you can't hand-write a `.shortcut` file

A shortcut on disk is a property list: WFWorkflowActions is an array of dictionaries, each with an action identifier and its parameters. That part is easy to write by hand.

The file has to be signed before anything will open it, and macOS ships a CLI for that:

shortcuts sign --mode anyone --input mine.plist --output mine.shortcut

It rejects hand-written plists. XML, binary, a minimal one-action file, a full set of top-level keys, both signing modes — every time, the same "isn't in the correct format." sign appears to accept only files the app itself produced.

Wall 2: `sign` doesn't work on a real file either

Fine — I got a real one (trick below) and tried again:

shortcuts sign --mode anyone --input real.shortcut --output out.shortcut
Error: In order to do this, you must be signed into iCloud.

I am signed into iCloud. iCloud Drive is on, the ~/Library/Mobile Documents/com~apple~CloudDocs folder is there, defaults read MobileMeAccounts shows the account. I tried it as a normal user process, through launchctl asuser, and in a real Terminal.app GUI session. Same error each time. On macOS 14.6, shortcuts sign seems to be simply broken. It may behave differently on other versions, but on 14.6 it's dead.

Wall 3: the import URL scheme only trusts iCloud

There's a URL scheme to import a shortcut from a link:

shortcuts://import-shortcut?url=<url>&name=Publora

Serve the file over local HTTP → "Import failed: the specified shortcut URL is invalid." Serve it over real HTTPS (I tried a gist) → same error. The scheme seems to accept only icloud.com/shortcuts/... links, i.e. files Apple itself signed. There's no side door.

Wall 4: you can't even read what's already installed

shortcuts list happily prints my shortcuts, so the data exists somewhere. But the group containers are empty shells, and the only SQLite files in them are four-kilobyte stubs from a migration folder. Nothing to read, nothing to use as a template.

The one thing that worked: pulling a shortcut out of an iCloud link

When someone shares a shortcut with you, the link is backed by an undocumented endpoint that returns the actual file:

curl -s "https://www.icloud.com/shortcuts/api/records/<share-id>" -o rec.json
# fields.name.value           → shortcut name
# fields.shortcut.value       → unsigned plist (readable, editable)
# fields.signedShortcut.value → Apple-signed blob

One catch: the downloadURL contains a literal ${f} placeholder you have to substitute before the download resolves.

Note: the values in the snippets below are anonymized — the IDs, keys, and parts of the endpoint response are not real. The point is that this path exists and that things travel out with the link, not a working recipe against other people's shortcuts. Exact behavior depends on the specific shortcut, so there's nothing to reproduce byte for byte here.

python3 - <<'EOF'
import json, plistlib, urllib.request
rec = json.load(open('rec.json'))
url = rec['fields']['shortcut']['value']['downloadURL'].replace('${f}', 'file')
open('raw.shortcut','wb').write(urllib.request.urlopen(url).read())
print(plistlib.load(open('raw.shortcut','rb'))['WFWorkflowActions'])
EOF

Now the shortcut can be read, diffed, and rewritten programmatically. You just can't push it back. This road is read-only.

The security part nobody warns you about

Look at that field list again. Everything baked into a shortcut travels with the link, and the link is public to anyone who has it. In my first working version, the API key was written straight into the header field. So for a while, my key was one URL away from anyone I sent the shortcut to.

That's the real lesson, and it isn't about reading other people's shortcuts — it's about what you hand out without noticing. If you're going to share a shortcut that talks to an authenticated API:

Never bake in a credential. Ask for it at runtime, or use Apple's import questions so the installer fills it in themselves.
Don't make the user hunt for internal IDs by hand. Ours calls GET /api/v1/platform-connections and reads the platformId itself.
When you're done testing, delete the iCloud link (Share → Remove iCloud Link) and rotate anything that may have leaked.

What this means if you were hoping to ship one

No build step. Shortcuts are GUI artifacts. No CI, no review, no git diff on a change.

No programmatic distribution. The installable artifact is an iCloud link, and only the app can produce it.

No store. Apple curates its own gallery inside the app, with no submission form. The real shelf is community catalogs like RoutineHub.

A per-user key is a hard ceiling. Anyone unwilling to paste a key won't install your shortcut, however nice the flow is.

What we shipped instead

The thing I actually wanted — tell an assistant, and the post goes out — turned out not to need Apple at all. Our MCP server (mcp.publora.com) does it in Claude and Cursor today, with no install and no key typed into a text field on a phone screen. And even the auth header is different there — MCP wants Authorization: Bearer, not the REST x-publora-key. No walls on that path.

I don't regret the evening. I now know exactly where the wall is, and I can read any shortcut someone sends me. Not enough to ship one. Enough to post.

Have you hit a wall trying to automate Shortcuts for real? Which one?

Chrome Rejected Us Twice. Firefox Approved Instantly. Edge Is Still Thinking

Eugeniya Ivanova — Wed, 22 Jul 2026 09:26:07 +0000

You have a few extensions installed right now, and you probably can't name them all. An ad blocker, a password manager, something you installed three years ago for one specific task that has been quietly living there ever since. That's normal: the average Chrome user has eight to twelve installed and actively uses two or three.

The whole point of an extension is to remove a context switch. Instead of opening a new tab, finding the service, logging in, and pasting the link, you get one icon right where you already are. The value is in skipping those five little steps, which is why extensions can look trivial until you start using one.

That was my situation. I write articles and then share them across social accounts: finish the piece, open our product in a new tab, copy the link, pick the accounts, send. Five context switches. Enough that I'd often leave it for later.

I wanted one button, so we built an extension. Click the icon and it pulls in the URL of the page you're on. You write your post and send it to the accounts you've picked without leaving the tab. The whole thing weighs seventeen kilobytes.

For scale: the Chrome Web Store held 283,585 extensions as of July 18, 2026, against 30,509 in Edge in mid-June and roughly 83,000 in Firefox earlier this year. Chrome is nearly ten times the size of Edge, which matters later. Meanwhile, extension trackers put the median at about eighteen users, with seventy percent sitting at a hundred or fewer. Everyone sees the giants, but a typical extension is used by a few dozen people.

Launching wasn't the interesting part. Over about two weeks, we went through three stores and collected two rejections and one HTTP 400 that locked out half the team. That's what this article is about, along with the actual wording we got.

What's inside

Manifest V3, a popup, and a small amount of logic. The extension reads a token from the logged-in tab of our product, exchanges it for an API key, and stores it in chrome.storage, so nobody has to copy anything by hand.

Here's the manifest we ended up with:

{ "manifest_version": 3, "name": "...", "version": "0.2.3", "permissions": ["storage"], "action": { "default_popup": "popup.html" } }

More interesting is what's missing.

Chrome turned us down twice

The first rejection came back as Spam and Placement / excessive keywords. In the description, we had listed all ten platforms the extension works with — LinkedIn, X, Instagram, and the rest — so readers would know where they could post. The automated filter read it differently.

Chrome's policy defines keyword spam as irrelevant or excessive keywords in a description used to manipulate ranking. On paper, we fit the definition: ten recognizable brand names in a row inside a short description look like an attempt to influence search, regardless of intent.

When your product genuinely supports ten networks, an honest list of them can look exactly like keyword spam. We fixed it by generalizing: "all your connected social accounts" instead of the full list, with no brand names at all.

The second rejection arrived as Use of Permissions. We had requested tabs but only ever called chrome.tabs.create, which doesn't require the tabs permission and works fine without it. It was a textbook case: permission requested, permission unused.

The policy requires the narrowest permissions necessary for your features, and the automated checks are good at spotting a gap between the manifest and the code. We dropped tabs and kept storage.

An iteration later, we added an "insert this page" feature, and that one needed activeTab — the narrow version of the permission we'd been rejected for. It's granted when the user clicks, applies only to the active tab, and the store has no problem with it. The lesson was simple: your manifest should contain exactly what your code actually calls.

Firefox: declare your data, get approved immediately

There was no rejection here, just a validator error for a missing property. Since November 3, 2025, every new extension has had to declare its data collection in the manifest through browser_specific_settings.gecko.data_collection_permissions. If you collect nothing, you still have to say so explicitly with none. Without that declaration, the build doesn't get signed.

"browser_specific_settings": { "gecko": { "data_collection_permissions": { "required": ["authenticationInfo"] } } }

After that came automated screening and almost immediate approval. Firefox was easily the fastest.

Edge: still waiting

Technically, it's the same Chromium and the same extension, but the differences start before you get anywhere near the code. The developer program won't accept a work or school account, so we had to register a personal Microsoft account in an incognito window to stop the browser from helpfully supplying the corporate one.

Then the validator said "manifest missing." The problem turned out to be the archive: manifest.json has to sit at the root of the ZIP rather than inside a nested folder. We repacked it flat with zip -j, and it went through.

Then we waited.

We got published, uploaded an update, and now we're waiting again. At least the current version stays available while the update is under review. Users keep running what's already live.

The HTTP 400 that only worked for me

The team went to test the extension, and every one of them hit HTTP 400 on auto-connect. It worked fine for me.

First, we ruled out authentication. A broken or empty token returns 401, and we were getting 400. The token was being accepted; something else in the request was being rejected.

Then came a false lead. While digging through the web app bundle, we found that it sends both an access token and a refresh token, while the extension was only sending the first. It looked like the answer. We fixed it. It didn't help.

Then I realized why it only worked for me. The code had a guard along the lines of if (apiKey) return. My key was already sitting in the cache, so the mint request never fired. I hadn't touched the branch that was failing for everyone else in months.

{ "error": "Maximum of 10 active API keys allowed" }

The extension minted a fresh key on every connect. Over a week of testing, people had accumulated ten keys and hit the ceiling.

That cost us most of a day and taught us two things. Never diagnose a 400 without reading the response body — the status code tells you the request was rejected, and only the server knows why, but it will usually tell you if you ask. And "works on my machine" can simply mean you have a cached result while the broken path only runs on a clean install.

A few other things came up along the way. Store review doesn't test your integration: the reviewer has no account in your product, so functional bugs sail through, because what's being checked is policy, permissions, and the listing — a green status only means you didn't break the store's rules. Screenshots have to show your real interface, since invented marketing graphics get spotted. Trader verification is its own saga, with Organization type, a D-U-N-S number, and a name and address that have to match the registry character for character or you get "no match." And Edge has its own asset dimensions and its own promotional tile, which can't include Chrome branding.

So was it worth it?

The extension is tiny, but it solves a problem I have every day, which is probably the best reason to build anything. If your product lives in a browser, an extension like this takes about a week to put together. Most of that time goes into working out what each store wants, and all three want different things.

Our extension is two days old. Now we'll see whether anyone else finds it as useful as we do.

We're digging further now, toward an add-on that would let you post straight from the document or deck you're working in. That's a different marketplace with different rules, so I suspect there'll be a part two.

Here's the link if you want to try it: Publora — Schedule Social Posts.

Have you shipped anything to the extension stores? What did they reject it for?

I Trained an AI to Sound Like Me. Then Spent Three Rounds Undoing It.

Eugeniya Ivanova — Mon, 20 Jul 2026 08:24:54 +0000

Let's get the disclosure out of the way: I wrote this with AI. This exact post went through the three rounds in the title, so if it reads clean, that's the point. If it doesn't, that's the more interesting comment.

It started some paragraphs, cleaned up others, and helped turn a pile of dictated notes into something readable. If you find a sentence that sounds suspiciously polished, tell me where. I'm curious which ones I missed.

I don't really think of an article as a finished object anymore. I write one version, then it has to travel. LinkedIn needs a different opening. X needs half the words. A newsletter can keep the context that a social post has to lose. Sometimes the same idea ends up in five places, each with its own limits and conventions.

This is where AI saves me a lot of time. It can cut, rearrange, reformat, and produce ten versions without getting bored. The original writing is another matter. I still don't trust it to do that alone.

Writing is fashionable to declare dead right now. Why bother learning when AI can generate a post in seconds? It reminds me of the way people talked about SEO around 2016. SEO didn't disappear. It changed, picked up a few new abbreviations, and carried on taking up everyone's time.

I suspect writing will do the same.

AI-generated text is already recognizable, although it isn't always easy to explain why. Certain phrases give it away immediately. "Here's what I found." "Not generic. Not robotic. You." "Honestly," placed at the start of a sentence as though everything before it had been dishonest.

The model reaches for these phrases when it needs a bridge but has nothing specific to add. Once you've edited enough generated text, you start spotting them before you've properly read the sentence.

The structure is often more revealing than the vocabulary. A text begins in ordinary paragraphs, then gradually turns vertical.

Like this.

One sentence per line.

Each thought given the same weight as the last.

Looks clean, doesn't it. Reads with a certain rhythm.

Then the paragraph snaps back to full width and you notice you'd stopped following an argument and started being walked down a list, with every thought given the same space and emphasis whether it earned it or not. It reads especially well on a phone, which is part of the problem.

You can tell the model to write in paragraphs, vary the sentence length, and avoid staccato. It will follow the instruction for a while, then drift back. That's the style it has seen rewarded across a huge amount of online writing.

The current panic about AI writing has also made careful human writing look suspicious.

I once wrote a comment entirely by hand. It had proper paragraphs, a clear structure, and punctuation exactly where I wanted it. An automated moderator removed it almost immediately.

No person read it and decided it was bad. A system decided, from the pattern alone, that it looked generated.

The comment was too orderly. The paragraphs were balanced, the argument moved cleanly from one point to the next, and apparently a real person was not expected to write that smoothly. I had been classified as a robot for taking the time to edit.

Since then, I've been skeptical whenever someone presents a list of definitive "AI tells." Sometimes those patterns do come from AI. Sometimes they come from people who know how to construct a paragraph.

The em dash is the most ridiculous example. Apparently it belongs to language models now. This thing, the one I just used, is supposed to be a confession.

I've been typing it for fourteen years. My fingers learned Shift-Option-hyphen long before I knew what a large language model was. I'm not going to retrain them because automated detectors have developed an anxiety about punctuation.

The dash is a poor test anyway. AI usually reveals itself at a larger scale: a rhythm that never changes, groups of three arranged a little too neatly, repeated "not X, but Y" constructions, and sentences that sound complete without containing much of anything. A single punctuation mark tells you very little.

So what do I actually do when AI has touched a draft?

First, I read the whole thing aloud. My eyes will accept a sentence because it looks polished. My ears are less forgiving. They catch the places where the language is doing more work than the idea.

Then I check the meaning sentence by sentence. What is this claiming? Where did that claim come from? Is it saying something concrete, or is it only moving me toward the next paragraph?

Unsourced facts either get a source or disappear. Tenses and numbers get checked separately because models mix both up with remarkable confidence.

After that, I give the draft to a second AI with a simple instruction: find and remove anything that sounds generated. It usually spots phrases I no longer notice because I've been staring at the text for too long.

Then I edit its edit.

In removing clichés, the second pass often removes meaning, tone, or some awkward detail that made the paragraph sound like me. It tends to solve messiness by making everything neutral. I compare the versions, put back what mattered, and rewrite the rest by hand.

That final pass is usually where the text stops feeling generated.

I have a personal list of things that make me pause: "delve," "seamless," "game-changer," empty bridges such as "here's what I found," too many mirrored contrasts, and staccato that runs through a whole piece. None of these is automatically forbidden. People use them too. But each one makes me check whether the sentence exists because I meant it or because the model needed something plausible in that spot.

The process isn't as new as it sounds. When I was learning to write, I did roughly the same thing with human editors.

Several of my friends are editors, and they were not gentle. They crossed out clever sentences, asked where facts came from, and pointed to the exact line where I had stopped saying anything. They argued with me when I defended a phrase only because I liked how it sounded.

Back then, I was training myself through repeated feedback. Now I'm training a model on top of that. The method has barely changed: show examples, explain what failed, revise, and don't accept the first pass just because it's grammatically correct.

I don't ask AI to "write in an interesting voice." That instruction usually produces a polished average of everything online. Instead, I give it concrete examples of writing whose rhythm I like and explain what I want it to notice: how long the paragraphs run, where the author gets specific, how jokes are placed, and which ideas are allowed to stay slightly rough.

Even then, the best results rarely begin with a blank page.

AI works much better when I give it a raw draft: dictated, repetitive, badly ordered, but mine. It can untangle the structure and cut the repetition without having to invent the material. Ask it to start from nothing and you generally get something competent that you'd never have chosen to say yourself.

The human still has to bring the observation, the story, and the reason for writing at all. A model is good at combing through that material. Give it a blank page and ask it to find the point, and that's where it starts to fall apart.

Once the article is finished, the balance changes. It still needs to become a LinkedIn post, a shorter version for X, an email, maybe a few replies. That work is repetitive, rule-based, and easy to verify. I hand it to AI without regret.

Publishing is repetitive too. I handle that through Publora now, which I'm part of, so weigh the mention accordingly. But the distinction holds no matter the tool: writing an idea and reproducing it across formats are two different jobs, and only one of them is the reason I started.

So no, I don't think writing is dead. I think the work around it is changing. There's more generated text to edit, more polished emptiness to catch, and more reason to know what your own voice sounds like before you ask a model to imitate it.

It's slower than typing "write me a post" and publishing what comes back. It also gives me something I can still recognize as mine.

AI helped write this article. Which sentence gave it away?

Why Your PNG Works on Threads and Dies on Instagram

Eugeniya Ivanova — Wed, 15 Jul 2026 12:45:05 +0000

You have one image to post to Instagram, Threads, and Bluesky. Two of those belong to the same company. It sounds like it should be easy.

Start with the file format. Instagram's docs say only JPEG is supported. Threads officially supports both JPEG and PNG. Same company, different rules — the exact same PNG uploads to Threads and gets rejected by Instagram.

Carousels are another one. Instagram allows up to 10 items; Threads allows up to 20, with a minimum of 2. Again: same company, same feature, different limits.

Then there are file sizes. Threads accepts images up to 8 MB. Bluesky's limit is exactly 1,000,000 bytes — not "about a megabyte," their own sample code rejects anything larger than 1000000. A 2.5 MB photo works on two platforms and fails on the third.

The bigger difference, though, isn't the limits. It's how the platforms expect images to reach them.

Meta doesn't want your file. It wants a URL.

You put the image somewhere publicly accessible, send image_url, and, as the docs put it, "we will cURL your image using the URL provided." So before you can publish an image to Instagram, you need somewhere to host it.

Bluesky works the other way around. You upload the bytes with uploadBlob, get back a blob reference, then include that reference in your post. The post never contains the image itself, it only points to it. Same idea, completely different model.

Meta also splits publishing into two steps: first you create a media container, then you publish it. The container expires after 24 hours, and if you miss the window you start over. Instagram recommends polling its status once a minute for up to five minutes. Threads suggests waiting about thirty seconds before publishing.

None of that shows up in the "post in three lines of code" examples. Your scheduler still has to deal with it.

Reels add another surprise. The upload endpoint isn't graph.facebook.com, it's rupload.facebook.com. Different hostname, same feature.

Bluesky has its own rules. Every image needs alt text, and if you don't have a description, you still send an empty string. It feels pedantic, but that's the API. The docs also recommend stripping EXIF data before upload — the server may enforce it later, but today it's still your responsibility.

One detail made me smile. Threads counts emojis against the 500-character limit by their UTF-8 byte length, so one 👋 counts as four. I'd already run into byte offsets while writing about Bluesky facets and assumed it was one of those open-protocol quirks. Apparently not.

Bytes come for everyone.

While we're talking about documentation, Instagram's own content publishing page says API-published posts are limited to 100 per rolling 24 hours. Further down the same page, in the carousel section, it says 50. Both numbers are in the official documentation.

At Publora we eventually ended up exposing one POST with content, platforms, and scheduledTime. For media you either provide mediaUrls — up to ten public HTTPS URLs in the same request, fetched server-side much like Meta does — or, if you're uploading local files, create a draft first, upload to a pre-signed S3 URL, then schedule.

If I weren't working on Publora, my advice would still be the same. If you're integrating with one network, use its native API: they're well documented, and you'll understand how the platform actually works.

Once you're supporting multiple platforms, the hard part stops being the HTTP requests. It's everything each platform quietly means when it says "upload an image."

I called Bluesky simple. Time for the asterisks.

Eugeniya Ivanova — Fri, 10 Jul 2026 09:59:27 +0000

In my last post I called posting to Bluesky "refreshingly straightforward." I still think that's true. I just stopped at "Hello, world."

Getting started really is easy. One request creates a session with your handle and app password. Another writes a record into app.bsky.feed.post. Two API calls later, your post is live.

Then you add a link.

The URL is sitting right there in the text, but it isn't clickable. Bluesky doesn't automatically treat URLs as links. Instead, you describe where the link appears using facets—metadata that points to the exact byte range occupied by the URL.

And "byte" is the word that ruins your afternoon.

If your post is plain ASCII, character positions and byte positions happen to match. Add Unicode, and they no longer do. Put one 👋 at the beginning of the post and every offset after it shifts. The text still looks right, but your facet now points somewhere else.

If you've ever wondered why the official SDK ships a RichText helper, this is why. It detects links, mentions, and hashtags, then computes the byte offsets correctly so you don't have to.

Tokens have their own catch.

Bluesky gives you two: a short-lived access token and a longer-lived refresh token. Log in and post immediately, and the access token is usually enough. Schedule the post for later, and it may have expired by the time the job runs. At that point, refreshing it becomes part of the normal publishing flow.

Images are another step of their own. Upload each image as a blob, then reference it in the post record. You can attach up to four images. The post itself is limited to 300 characters, so if you're over the limit, deciding what to cut is your responsibility.

None of these pieces is especially difficult. The friction comes from having to deal with all of them yourself. "Send a post" quietly becomes "calculate byte offsets, refresh tokens, upload blobs, validate limits."

That's perfectly reasonable if you're building directly on AT Protocol.

At Publora, we hide those details behind a single request: content, platforms, and an optional scheduled time. Facets for links, mentions, and hashtags are generated automatically, tokens are refreshed when needed, images are uploaded, and posts over 300 characters are trimmed to fit. It's the same Bluesky API underneath—we just take care of the repetitive parts.

I'm obviously biased, so here's the recommendation I'd make anyway: if you're building specifically for Bluesky, use the official SDK. It's well designed and saves you from implementing the fiddly bits yourself. But once Bluesky becomes one destination among several, another layer starts to make a lot of sense.

The first two API calls really are refreshingly simple.

Everything after them is the actual integration.

Mastering the AT Protocol: Building a Full-Featured Bluesky CLI from Scratch

#automation #bluesky #cli #atprotocol

8 min read

Drafted with AI, then reviewed against the Bluesky documentation and Publora's own implementation guide before publishing.

Why Every AI Agent Eventually Fights Social Media APIs

Eugeniya Ivanova — Tue, 07 Jul 2026 13:29:35 +0000

AI agents have gotten weirdly good at writing.
You can hand one a vague prompt and get back something publishable. The trouble starts one step later, when you ask it to actually press "post."
"Post this to LinkedIn" sounds like one API call. In practice it's multiple OAuth flows, a few different media upload pipelines, review-gated permissions, token refresh logic, rate limits, and a scheduler for the moment you decide you'd rather not publish at 3am.
The model isn't the hard part anymore.
The integrations are.
If you're building agents that publish, here's what that landscape actually looks like.

One network? Native is great.

Let's start with the easy case. Posting to Bluesky via the AT Protocol is refreshingly straightforward.

# Create a session
curl -X POST https://bsky.social/xrpc/com.atproto.server.createSession \
  -H "Content-Type: application/json" \
  -d '{"identifier":"you.bsky.social","password":"'"$BLUESKY_APP_PASSWORD"'"}'

# Create a post
curl -X POST https://bsky.social/xrpc/com.atproto.repo.createRecord \
  -H "Authorization: Bearer $ACCESS_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "repo": "<your-did>",
    "collection": "app.bsky.feed.post",
    "record": {
      "text": "Hello Bluesky 👋",
      "createdAt": "2026-07-10T09:00:00Z"
    }
  }'

Two requests. That's the whole thing.
Now imagine doing that for LinkedIn, X, Instagram, Facebook, Threads, and Mastodon—none of which were designed together, or, from the look of it, designed to be aware the others exist.
There isn't really a "social media API." There are half a dozen unrelated APIs that happen to share a hobby.

Every platform has its own rules

Platform	Authentication	Biggest friction
LinkedIn	OAuth 2.0	App review for advanced publishing
X	OAuth 2.0	Pay-per-use since Feb 2026 — ~$0.015/post, $0.20 if it has a link
Instagram / Facebook / Threads	Meta Graph API	Business account + App Review
Bluesky	App password or OAuth	Almost no friction
Mastodon	Token per instance	Every instance is effectively its own API

The pattern shows up fast. Open networks like Bluesky and Mastodon are easy to build against; the big commercial platforms want app reviews, business verification, paid access, or all three.
X earns its own line here. Writing isn't just paid—it's paid per link. A plain post runs about $0.015, but a post with a URL costs $0.20. Which is a delightful surprise for an agent whose entire job is sharing links. You built automation to save time, and now it's quietly running up a tab, twenty cents at a time.

The integration work sneaks up on you

Generating content is easy. Keeping the integrations alive is the actual job.
Every platform authenticates differently, uploads media differently, scopes differently, fails differently, and expires its tokens on its own private schedule. Scheduling, half the time, isn't supported at all.
At some point your AI project quietly turns into an OAuth project.

Where MCP fits

One way out is to stop teaching the agent about every platform individually, and instead expose publishing as a single tool.

With the Model Context Protocol (MCP), an agent discovers available tools with tools/list and calls them with tools/call. Under the hood it's plain JSON-RPC.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_post",
    "arguments": {
      "content": "Hello from an agent 👋",
      "platforms": [
        "linkedin",
        "bluesky"
      ],
      "scheduledTime": "2026-07-10T09:00:00Z"
    }
  }
}

The interesting part isn't MCP itself. It's the abstraction.

The agent calls one tool. Something behind that tool deals with OAuth, retries, uploads, scheduling, and whatever mood each platform is in today.

It's a pattern engineers already know by heart: hide the provider-specific mess behind a stable interface, and try not to look at it too often.

I'm skipping the protocol tour on purpose—teaching MCP from scratch would pull this post somewhere it doesn't need to go. If you want the proper walkthrough of tools/list, tools/call, and the JSON-RPC plumbing underneath, other people have already done it well:

楊東霖

Mar 20

MCP Server Tutorial: Build Your First Model Context Protocol Server Step by Step

#webdev #programming #tools #productivity

18 min read

…and the official MCP docs are the canonical reference. No point in me repeating what they cover better.

Connecting an MCP server

A hosted MCP server is usually just an endpoint and a key. Here's how I connect the one we built at Publora:

claude mcp add publora \
  --transport http https://mcp.publora.com \
  --header "Authorization: Bearer $PUBLORA_API_KEY"

Publora, your own server, someone else's implementation—it doesn't matter for the point. The architecture stays the same: your agent calls one tool instead of maintaining a relationship with five different APIs.

Things that cost far more time than expected

Scheduling
Most APIs publish immediately. If you want scheduled posts, you're building a queue, retries, and a scheduler yourself—congratulations, you now maintain infrastructure.

Media uploads
Uploading media is almost never one request. Usually it's three:

Ask for an upload target.
Upload the file.
Reference the returned media ID.

And every platform has its own opinion about steps one through three.

Partial failures
"Publish everywhere" is never atomic. Three platforms succeed, one rate-limits you, and one rejects your image for reasons it declines to specify. It's a group project, and one member has gone quiet.
So now you need retry policies and a way to tell the user what actually happened without lying to them.

Formatting
Character limits, mentions, hashtags, markdown, media rendering—every platform supports roughly the same ideas and implements none of them the same way. The same post rarely looks identical in two places, and occasionally it shows up in one of them looking like a ransom note.

Token management
OAuth refresh tokens, app passwords, per-instance tokens—each with its own expiration rules and its own refresh flow. Authentication itself isn't the hard part. Supporting all of it at the same time, forever, is what quietly eats your week.

So... should you build it yourself?

If you're targeting one open network like Bluesky—absolutely, go native. The APIs are clean and you'll come out understanding the protocol properly.
Once you add several networks, plus scheduling, media, and retries, the math flips. Not because any single request is difficult, but because maintaining six integrations is not the reason any of us got into this.

Takeaway

AI didn't make social media publishing easier. It just made it impossible to ignore how fragmented the whole thing already was.
The hard part isn't generating text anymore. It's everything wrapped around it: auth, permissions, uploads, scheduling, retries, and a long tail of platform-specific edge cases.
Whether you handle that with direct integrations or hide it behind MCP is an architectural call. Knowing where the complexity actually lives is the part worth keeping.

I work on Publora, so that's the MCP server I know best—and it's open source (MIT) if you want to poke at it. But even if you never touch it, try wiring something up to Bluesky's AT Protocol, or stand up a tiny MCP server of your own. It's one of those weekend projects that makes all the trade-offs obvious by Sunday.
What are you using to connect your agents to the outside world these days?

Drafted with AI, then read start to finish by an actual human—which, given the topic, felt like the least I could do.

DEV Community: Eugeniya Ivanova

I tried to build an Apple Shortcut from code. Apple said no, four times.

What works

Wall 1: you can't hand-write a `.shortcut` file

Wall 2: `sign` doesn't work on a real file either

Wall 3: the import URL scheme only trusts iCloud

Wall 4: you can't even read what's already installed

The one thing that worked: pulling a shortcut out of an iCloud link

The security part nobody warns you about

What this means if you were hoping to ship one

What we shipped instead

Chrome Rejected Us Twice. Firefox Approved Instantly. Edge Is Still Thinking

What's inside

Chrome turned us down twice

Firefox: declare your data, get approved immediately

Edge: still waiting

The HTTP 400 that only worked for me

So was it worth it?

I Trained an AI to Sound Like Me. Then Spent Three Rounds Undoing It.

Why Your PNG Works on Threads and Dies on Instagram

Further reading

I called Bluesky simple. Time for the asterisks.

Further reading

Mastering the AT Protocol: Building a Full-Featured Bluesky CLI from Scratch

Why Every AI Agent Eventually Fights Social Media APIs

One network? Native is great.

Every platform has its own rules

The integration work sneaks up on you

Where MCP fits

MCP Server Tutorial: Build Your First Model Context Protocol Server Step by Step

Connecting an MCP server

Things that cost far more time than expected

So... should you build it yourself?

Takeaway

DEV Community: Eugeniya Ivanova

I tried to build an Apple Shortcut from code. Apple said no, four times.

What works

Wall 1: you can't hand-write a .shortcut file

Wall 2: sign doesn't work on a real file either

Wall 3: the import URL scheme only trusts iCloud

Wall 4: you can't even read what's already installed

The one thing that worked: pulling a shortcut out of an iCloud link

The security part nobody warns you about

What this means if you were hoping to ship one

What we shipped instead

Chrome Rejected Us Twice. Firefox Approved Instantly. Edge Is Still Thinking

What's inside

Chrome turned us down twice

Firefox: declare your data, get approved immediately

Edge: still waiting

The HTTP 400 that only worked for me

So was it worth it?

I Trained an AI to Sound Like Me. Then Spent Three Rounds Undoing It.

Why Your PNG Works on Threads and Dies on Instagram

Further reading

I called Bluesky simple. Time for the asterisks.

Further reading

Mastering the AT Protocol: Building a Full-Featured Bluesky CLI from Scratch

Why Every AI Agent Eventually Fights Social Media APIs

One network? Native is great.

Every platform has its own rules

The integration work sneaks up on you

Where MCP fits

MCP Server Tutorial: Build Your First Model Context Protocol Server Step by Step

Connecting an MCP server

Things that cost far more time than expected

So... should you build it yourself?

Takeaway

Wall 1: you can't hand-write a `.shortcut` file

Wall 2: `sign` doesn't work on a real file either