DEV Community: Eugeniya Ivanova

I got our API into the Postman network in one evening — and didn't hand-write a single request

Eugeniya Ivanova — Tue, 18 Aug 2026 07:30:59 +0000

About a quarter of our users access the API with a key. The main barrier isn't code, it's the first half hour: open the docs, figure out which endpoints you need, put together the first request, find where the key goes. The Postman network skips most of that. You get ready-made collections you can fork into your workspace and run with your own key. We're in there now, next to Notion, Stripe, and Twilio — and getting listed took one evening. Here's how I did it, and why I decided not to build the collection by hand.

First, a pleasant surprise. Getting listed anywhere usually means sitting in someone's review queue — Chrome, Edge, and LinkedIn have all made us wait. Postman doesn't work that way: it's self-serve, publishing is free, and there's no application or moderation. So the whole thing really did fit into an evening.

You can build a collection for the network by hand: create the requests, type in the paths, fields, and headers. Plenty of people do. The problem is that a hand-built collection is a snapshot of your API on the day you made it. Add an endpoint or rename a field a month later, and now the collection is out of date.

So I didn't write ours. I imported our OpenAPI spec. Ours is public and has 29 paths:

https://docs.publora.com/openapi.json

The import is one call to the Postman API:

curl --location 'https://api.getpostman.com/import/openapi' \
  --header 'X-Api-Key: PMAK-YOUR-KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "type": "json",
    "options": { "folderStrategy": "Path" },
    "input": <contents of openapi.json>
  }'

That means the paths, fields, and types come straight from the spec and match the actual API. When the API changes, you can regenerate the collection from the latest spec instead of manually syncing everything again.

There's one thing to watch for. Notice folderStrategy: "Path" — Postman organizes the imported requests by URL path. That's technically correct, but not particularly nice to browse: you end up with a wall of paths instead of useful groups. So importing was only half the job. I reorganized the collection through PUT /collections/{uid} into something a person can actually navigate:

Connections   3   connected accounts, platform limits, connection test
Posts         6   create, schedule, get, update, delete, logs
Media         5   three-step file upload, Reels cover, YouTube thumbnail
LinkedIn      9   analytics, followers, comments, reactions, repost
Webhooks      5   notifications instead of polling
Workspace     6   managing client accounts

A note about keys, since this is a public catalog rather than my private workspace. Authentication came from the spec automatically: the x-publora-key header gets its value from an apiKey variable, and that variable is empty. Anyone who forks the collection adds their own key. I checked the published version to make sure mine wasn't there. And if you're doing this yourself, don't put your Postman key (PMAK-…) in the collection either. You need it for the import call, not for the public collection.

Instead of writing a long introduction, I added a short "first post in 60 seconds" and a "where everyone trips" section. That felt more useful than repeating the docs. It covers the things we see people get wrong: copy the platformId exactly or the post can go to the wrong account; Instagram and TikTok don't accept text-only posts; leave out the publish time and you get a draft rather than a published post; comments are LinkedIn-only; and you can test the whole flow without publishing anything by using the publora-playground target.

Two things tripped me up, so they're worth mentioning.

Workspace visibility can't be changed through the API. You can do almost everything else in code, but switching the workspace from Internal to Public has to be done manually in settings — in the same place where you rename the team. Not a big deal once you know, but I spent some time looking for an API setting that doesn't exist.

And one more general lesson: trust the machine-readable spec over the overview page. Overview docs can lag behind the API. The spec is much more likely to reflect what's actually implemented. If I'm wiring up an integration against someone else's API, that's where I'd look first.

The short version: getting into the Postman network can take an evening, and the useful shortcut is not writing the collection by hand. Generate it from the spec, clean up the structure, leave the key field empty, and regenerating it after API changes becomes much easier.

If you're in Postman and want to have a look, here's our collection: Publora API on Postman.

For those publishing your own APIs: do you generate collections from the spec or still build them by hand? And how often do you find your overview docs have drifted from the actual spec?

We shipped a one-click 'Add to Cursor' button. The hard part wasn't the button.

Eugeniya Ivanova — Mon, 10 Aug 2026 12:17:01 +0000

My job is getting our product into people's hands. It's built for AI agents, so it has to live where agents pick up their tools — in their catalogs. Slow business: we're in the review queue at the big ones as I write this. And getting listed is only half the job. The other half is making sure connecting isn't a scavenger hunt through config files, pasted keys, and hopeful restarts.

So we started with a button. One click, Publora's in Cursor. Sounds like an evening's work.

It wasn't.

Cursor installs MCP servers from a deeplink — a link that tells the editor to add a given server:

cursor://anysphere.cursor-deeplink/mcp/install?name=Publora&config=<base64>

The config is a base64-encoded JSON holding the server address. Official format, everyone uses it, Asana and Xano included. We built the button, the link generated cleanly, the base64 decoded into exactly the right config. Everything checked out.

You click it, and: connection failed. Before it ever reached authentication.

My first guess was the key. It won't connect, so it must be access, right? Wrong, and that wrong guess is where the time goes.

The button doesn't ask for a key, it drops in a placeholder. Cursor sends that placeholder, the server returns a perfectly correct 401, and instead of reporting a bad key, Cursor falls back to OAuth. It goes looking for OAuth settings at the standard spot, /.well-known/oauth-authorization-server. Our server answered there with a custom response of its own — not the shape the spec describes. Cursor tried to parse it as OAuth metadata, found none of the fields it needed, printed "MCP OAuth provider initialized," and stopped there.

Placeholder instead of a key, then a 401, then a fallback into OAuth, then a failure on our non-standard response. The key was never the problem. It's just the first thing everyone suspects.

Our first fix was simple: type a real key in by hand. Cursor has a little pencil that opens ~/.cursor/mcp.json, you swap the placeholder for a real sk_..., and it goes green. A valid key means the request never reaches OAuth discovery at all — the server just answers and hands over its tools. Fine. But "one click, now paste your key" is a click and a half, and not the button we came to build.

Now, before anyone asks why we didn't do it properly from day one. A key instead of OAuth wasn't us cutting corners. It's where the whole ecosystem started: the MCP spec recommended API keys until March 2025 and only then made OAuth the baseline. The thing has been rewritten three times in nine months — catching up to that is not an evening either. This same .well-known is currently tripping up companies with rather more headcount than us: Atlassian has an open bug about OAuth-metadata validation, and Microsoft's own MCP clients resolve the endpoint wrong. And when one study checked 660 OAuth servers, 27 of them — four percent — did full dynamic registration. Moving from a key to real OAuth isn't the slow kid's homework. It's the part most products just never finish.

So instead of hiding the key, we fixed the place everything kept dying on. Cursor wants OAuth so badly? Give it OAuth. My engineers put proper, to-spec metadata at /.well-known/oauth-authorization-server — issuer, authorize and token endpoints, client registration, PKCE, the whole set the editor kept hunting for. My contribution at this stage was reading closely and sitting next to them waiting for a miracle. It arrived.

The chain runs straight now. Click the button, Cursor fetches the OAuth settings, finds real ones, pops the Publora login, you sign in, and it collects the token itself. Nothing typed by hand. The one click, as advertised.

To reproduce it, it comes down to two things. A deeplink whose config is just { "url": "https://mcp.publora.com/mcp" } — the address, no key, login goes through OAuth. And a server that serves valid metadata at /.well-known/oauth-authorization-server instead of something homemade. If your client prints "OAuth provider initialized" and then quietly dies, put your money on this: it read your .well-known and didn't find what it wanted.

The big catalogs are still ahead of us, moving at their pace and not ours. The Cursor install works today. So if you're in Cursor and you use Publora, poke the button and tell me how it went — genuinely curious, especially if it breaks somewhere new.

LinkedIn gave everyone a 'this looks like AI' button. I won't press it.

Eugeniya Ivanova — Tue, 04 Aug 2026 11:29:33 +0000

This week LinkedIn rolled out a "Seems like AI slop" button. Tap it under someone's post and the post disappears from your feed, while your report goes off to train their filter. I heard about it through work — keeping an eye on what platforms are up to is part of the job — but I read it less as a marketer and more as someone who writes, and who now, apparently, walks around under suspicion.

LinkedIn's logic isn't hard to follow. According to the AI detector Pangram, they have the highest share of AI content of any platform: roughly a third of short posts and over forty percent of long ones. The feed really is drowning, and handing people a valve is a reasonable move.

It isn't the valve that bothers me. It's whose hands it got put in.

The "this is AI" verdict used to come from an algorithm, and even that missed plenty. Pangram itself claims a 0.01% false-positive rate — which sounds impressive until you multiply it by volume. One hundredth of a percent of millions of posts is still thousands of real people getting labelled as bots. And that's the machine, the one somebody at least tested. Now the "this is AI" stamp has been handed to every passerby, and the cost of getting it wrong is zero. Tap, post gone, on with your coffee. You'll never even find out you were wrong — there's no feedback loop pointing back at you.

I haven't touched the button once, and I don't even like AI text — the smooth filler I spent a whole post pulling apart last time. But disliking slop and swatting a person are different reflexes with different results. Someone posts the best thing they know how to write, and someone else decides it "looks like a bot." That's one reader gone. That isn't fighting slop. That's slapping the hands of someone who's only just reaching for the keyboard.

Here's the personal part. I write with AI and I don't hide it, but the text is mine: a pile of rules, defined styles, years of tuning, every paragraph edited by hand. Slow — though it used to be slower. AI isn't my author, it's a tool I don't let grab the wheel. I wrote a whole article about that.

Then something happened that made it feel a lot more personal. A while back, in a work chat, I answered a former colleague — a plain message, a couple of paragraphs. She reads it and says: "Wow, you sound just like GPT — fast and structured." A compliment. The catch is that about two minutes passed between her question and my answer. There wasn't even enough time to open ChatGPT, write a prompt, wait for an answer, and paste it back. It was just a human who's spent a long time working with words. And it read as a machine.

And for a couple of days I was pleased about it — imagine, mistaken for GPT, fast and clean. Now it turns out that's exactly the thing I'm supposed to worry about. Same sentence. Same moment. A week later it had gone from a compliment to evidence, while nothing about me had changed. What changed is that there's now a button for it.

Fluency is being read as forgery. Fast and clean means you didn't write it yourself, and there's now a button wired to that assumption.

The irony is that AI was trained on well-edited human prose — which is exactly why it comes out so smooth and combed. And that smoothness is now how we try to spot it: we hunt for the fingerprints of a good editor, and we reliably find them on people who simply know how to write. Congratulations to all of us.

My own way out of this is as old as it gets: divide and conquer. The machine is fast and a little too good — and sometimes not good at all, and that's the line I can still see and it can't. I handed it the posting across networks; works great — it's mechanical anyway. But writing is different. No matter how much I train it, it keeps sliding back into "we did it this way before, so this must be right." Except the new piece in front of it doesn't fit the old rules, and it doesn't notice that — I do. So here's the split: authorship and judgment stay with the human, logistics go to the machine. That's how I run it through Publora (I'm on the team): I write by hand, and the delivery across platforms goes to an agent. No AI writes my posts — it's on backup duty, in the corner, not at the wheel.

How this ends, honestly, I don't know. For now I've stocked up on popcorn and I'm watching from two angles. Angle one: people start writing worse on purpose — breaking the rhythm, sprinkling in typos, watering it down, anything to avoid looking suspiciously smooth. A platform that penalizes quality, and a crowd cheerfully dumbing itself down to a C. Angle two: some just stop posting, because the fun runs thin when any passerby gets to weigh your fluency for "real or not." Which one wins, I won't guess. Popcorn's ready.

I still won't press the button. Slop exists, no argument, plenty of it. But pressing something in two seconds, with zero accountability, that sorts people into "human / not human" — that I'm not up for.

By the way, a huge secret: I wrote this article myself, by hand. The formatting and posting I handed to an agent — the writing was mine, the publishing wasn't, and that's exactly how I want it.

Would you press it? And have you ever caught yourself deciding someone's fast, clean writing was too smooth to be real?

You're writing for two readers, and one of them is a model

Eugeniya Ivanova — Thu, 30 Jul 2026 11:28:17 +0000

Every post you write now goes to two readers.

The first is a person. They open it, read it, decide whether it was worth their time. Nothing new there — we've been writing for that reader forever.

The second reader showed up recently, and it isn't a person. It's a model. It reads your text, works out what it's actually about, and decides whether to surface it or quote it in an answer. You're writing for both now. They want slightly different things — but less different than you'd fear.

LinkedIn is the easiest example because they published how it works. Their engineering post describes the new way content gets picked: instead of the old pile of separate pipelines, there's now an LLM retriever that turns every post and every profile into a vector of meaning, then pulls a couple thousand candidates out of millions by how close those meanings sit. That's the first point where a model reads your text. Before anything gets ranked, something has already worked out what you wrote about.

Here's the part almost every write-up got wrong. The retrieval runs on an LLM, yes. But the final ranking of those candidates isn't done by a language model — it's a separate transformer called Feed-SR. In their own paper, LinkedIn says plainly that they tried an LLM ranker and chose not to ship it: the transformer scored better and cost less to run. So "the feed is one giant LLM now" isn't what happened. The LLM sits exactly where it's decided whether your text gets considered at all — at the reading-for-meaning step.

There's one catch worth mentioning. Online, everyone calls this system "360Brew" and recites its exact rules. 360Brew is a pre-production research model from a separate paper whose every version on arXiv is marked withdrawn, and LinkedIn never confirmed it runs the feed. Their own Feed-SR paper contradicts the story directly. Somewhere along the way, someone attached a catchy name to a real engineering paper, and everyone else repeated it. If a source can't get the name of the engine right, treat its "exact rules" as a guess too. Read the primary source, not the recap of a recap.

The name isn't the important part. The shift is. The feed used to be gameable with mechanics — keywords, early-hour posting windows, pods trading likes. Now there's a model at the door that reads for meaning, and you can't fool it with the tricks that fooled a counter. It reads roughly the way an assistant reads a question you asked it.

That's where the two readers start looking surprisingly similar. The assistant looking for the answer to a professional question and the feed retriever deciding whether to surface your post are doing the same job: reading the text for whether there's a specific point about a specific thing. What lands with the first lands with the second. Neither gets much from smooth, empty writing; both reach for text where it's clear what it's about and who it's for.

This doesn't mean you should start writing for the algorithm. If anything, it points in the opposite direction. Writing for the machine used to mean writing worse: stuff in keywords, pad to length, staple on five hashtags. Now the machine reads like a reader, so writing for it means writing more clearly. Don't try to please the algorithm. Try to be understood. One concrete point beats ten blurry ones. An example someone can quote beats a paragraph of generalities. A topic you can be pinned to beats trying to appeal to everyone.

There is one trap, though. Optimizing to "get quoted by a model" is a slippery road, and at the end of it waits exactly the AI slop I spent last time learning to scrub out — the confident, weightless prose that says nothing. The irony is that the model at the door doesn't like it either; it tells specific from smoothly-empty about as well as a person does. Push that too far and you end up writing for neither. The only thing that seems to work for both is having something specific to say.

LinkedIn just happened to show how the system works first. Everything that retrieves and quotes you — search, assistants, feeds — is moving the same way, from "how many signals did you stack" to "what is this actually about." What people buried as SEO back in 2016 didn't die. Search just stopped counting and started reading.

So yes, you've got two readers now. But write honestly and to the point, and the second one isn't extra work. It wants the same thing the first one does.

Have you caught yourself writing with one eye on how a model will read it? Does the text come out better or worse for it?

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 got our API into the Postman network in one evening — and didn't hand-write a single request

We shipped a one-click 'Add to Cursor' button. The hard part wasn't the button.

LinkedIn gave everyone a 'this looks like AI' button. I won't press it.

You're writing for two readers, and one of them is a model

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 got our API into the Postman network in one evening — and didn't hand-write a single request

We shipped a one-click 'Add to Cursor' button. The hard part wasn't the button.

LinkedIn gave everyone a 'this looks like AI' button. I won't press it.

You're writing for two readers, and one of them is a model

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