DEV Community: Eugeniya Ivanova

My MCP integration got rejected. Almost nothing in the server had to change.

Eugeniya Ivanova — Mon, 07 Sep 2026 07:54:22 +0000

In July I set out to add our MCP server to the ChatGPT app directory. The server was already live, running in Claude and Cursor, with OAuth working. Submitting looked like a formality: describe what already exists, fill in the application, hit Submit.

A month and one rejection later, almost nothing had changed in the server itself. It had been working the whole time. What we ended up fixing was everything around it: how ChatGPT discovers the tools, what the scanner expects, what we'd written in the descriptions, and whether a reviewer could actually log in.

Here's what caught me.

The tool list that freezes solid

The first problem came before submission. I connected the server to ChatGPT — the connector was created, but it showed "no actions available." Zero tools. In Claude and Cursor the same tools loaded fine.

I spent a while looking at SSE and caching. Neither was the problem. ChatGPT reads the tool list when the app is created, and if the server returns zero at that point, the app can get stuck there. "Refresh" is disabled at zero and "Save" is greyed out. In my case, the way out was to delete the app and create it again.

The server returned zero because it required a token for tools/list itself. Claude logs in first and fetches the list afterwards, which is why we'd never seen the problem there. ChatGPT fetches the list before authorization, gets nothing, and turns to stone. So now I check one thing before doing anything else: tools/list needs to return 200 with the tools and no token.

Annotations the scanner demands and the spec doesn't

Next, OpenAI's scanner went through every tool and required explicit readOnlyHint, openWorldHint and destructiveHint values. Four read-only tools didn't have destructiveHint, which made sense according to the MCP spec: it only matters when readOnlyHint: false.

The scanner wanted it anyway. We added destructiveHint: false to those tools and wrote justifications for forty-odd annotation values. The tools themselves didn't change. We just had to make explicit something the spec allowed us to leave implied.

The domain challenge that wants a bare string and lives forever

A small one that's easy to waste time on: OpenAI's domain verification expects the endpoint to return a bare token string. No JSON, no quotes. Return {"token": "..."} and it fails.

It also isn't a one-time verification endpoint. It has to stay there in production, answering the same way afterwards. So we now have a tiny endpoint with one permanent job: return a string when OpenAI asks.

The drift I caught on myself

Then I found something that actually was our mistake.

Our public mcp-server repo defines 18 tools, four of them for LinkedIn analytics: post stats, account stats, followers and profile summary. The live server exposes 16, and none of those analytics tools are among them. They exist in the REST API, but aren't exposed through MCP.

The public repo had fallen behind the live server, and the app description was based on the repo. So we were describing analytics that someone using MCP couldn't actually access. I removed them from the description and release notes.

Then I found the same old description in two more places: the README for the Zed extension and the PR for the Docker MCP Catalog. The Zed PR was also pointing at a commit from before the correction, so merging it would have put the outdated claim into another catalog. We'd updated the product and missed a few places where we'd described it. Easy enough to do when those descriptions live in different repos and submissions.

The rejection that wasn't about the code

Submitted August 5, every wizard step completed in one pass. Rejected August 24.

The message was: "We're unable to complete your sign-in or OAuth flow… ensure valid, working credentials… no additional setup or verification."

Before changing anything, I walked through the flow again. Dynamic client registration returned 201. /authorize sent me to our consent screen. The sign-in page in a clean browser was a normal email-and-password form with no captcha. tools/list without a key returned the tools. API and MCP access were enabled on every plan, including free. Everything worked.

Then we looked at the account we'd given the reviewer.

Our own accounts use Google sign-in. A reviewer can't use our Google account, and even if they tried, the second factor would land on our phone. We'd managed to give them credentials for an account they had no way to get into.

Even worse, Canva had rejected us for the same reason before. Twice was enough to stop calling it bad luck. We simply didn't have "can a stranger actually use these credentials?" on our submission checklist.

What actually fixed it

We created a separate reviewer account: email and password, email confirmed ahead of time, a couple of channels connected, with some posts and drafts already there. We also included eight test cases — five positive and three negative.

The most useful one was a full write-path test through publora-playground. It's a fake publishing target: it validates the post against the same rules as a real one and returns the same kind of response, but throws the request away at the end instead of publishing it anywhere. A reviewer can go through the whole publishing flow without putting a test post on someone's actual timeline.

It took about thirty lines and ended up being one of the most useful things we added for the submission. The reviewer could finally test writes without needing a disposable social account.

We resubmitted on the evening of August 24. Approved September 4.

What I wrote down for next time

The main addition to my submission checklist is pretty basic: go through the product as the reviewer, not as yourself.

The server worked in Claude and Cursor. It followed the spec. OAuth worked when we tested it. But ChatGPT asked for the tool list in a different order, its scanner expected metadata we hadn't needed elsewhere, and the reviewer needed a login that didn't depend on being us. Those were the things that took the month.

I did this with Claude — it wrote the code and configs, while I checked what was happening and decided what needed changing. The funny part is that almost none of those decisions involved changing the server itself. Most of the work ended up being metadata, descriptions and access.

What's gotten your product bounced from a platform review — something actually broken, or something you never thought a reviewer would run into?

I sell social media automation. My survey says people want the opposite.

Eugeniya Ivanova — Thu, 03 Sep 2026 08:07:39 +0000

I work at Publora — an API and MCP for publishing to social networks from one place, including through an AI agent. So, in a sense, my job is selling automation for posting. Which made the answers I started getting from actual people a little awkward.

I've been doing a small study — nothing fancy, just messaging people directly and asking: what do you use to post, and why do you do it that way? No pitch, no setup. It's an ongoing thing, reaching out to people across different niches one by one, so this isn't a clean statistic — more a pile of honest answers I'm still adding to. A few hundred replies in, and I'm still going.

The answers are all over the place, but one thing keeps coming up. People aren't asking for more automation. Quite a lot of them want to keep the final step for themselves.

A few answers, anonymized.

One person told me: "I use AI rarely, do the core work myself. Sometimes I go into ChatGPT or Gemini as a 'second brain' — when I'm out of ideas or a deadline's closing in. But at the end of the day it's still just a machine."

So AI is useful to think with. That doesn't mean they want it doing everything.

Another: "I use Claude, but not for posting — it sort of sets me up, and I publish myself."

And a third was very direct: "I'm wary of AI tools having access to my account. LinkedIn isn't forgiving about it."

That one wasn't really about whether AI-written posts sound authentic. They simply didn't want another tool having that much access to their account.

Then there was this: "I like hitting publish myself. In a world where everything's polished, it makes the content feel a little more alive."

Different reasons: sometimes security, sometimes control, sometimes just liking the fact that there's still a person involved. But I kept hearing versions of the same thing. Draft for me, help me think, prepare it — fine. I'll publish it.

Nobody was dreaming about an agent happily posting all day while they went for coffee.

At first this was slightly uncomfortable to hear, considering what I do for a living. But the more replies I read, the less it sounded like an objection to automation. It sounded more like people being quite specific about which parts they actually want automated.

Where that caution stops being a quirk

One answer stood out because it came from someone managing several brands rather than just their own account.

They prefer tools with integrations because content and reporting are easier there than doing everything natively. The problem is that not every platform has the integrations they need, and the more channels a brand uses, the messier the whole setup gets.

That changes the problem quite a bit.

Being cautious about giving AI access to your own LinkedIn account is one thing. Being an agency responsible for ten clients' accounts is another. Now you're dealing with reputations that aren't yours, client credentials, several calendars, approvals living somewhere in email, and the possibility of someone putting one client's post on another client's account.

At that point, automating everything sounds terrifying. Doing everything manually isn't much better. Ten clients still have to fit into the same working day.

So you need something in between.

What that looks like in practice

After reading the replies, I kept coming back to three things.

The first is keeping clients separate. Each one needs their own connections, content and calendar, without the possibility of a post quietly ending up on somebody else's account. A posting mistake on your own account is embarrassing. Doing it to a client's account can get expensive.

The second is passwords. Ideally, an agency shouldn't have them at all. The client connects their account through an OAuth link, and the team can work with it without ever knowing the login. The person who told me they were wary of tools having access to their account wasn't being paranoid. That's a perfectly reasonable thing to worry about.

And then there's approval. An agent can draft a post. It can prepare it, schedule it, do the repetitive bits. But publishing can still wait for a person to approve it. In a team, that can also mean the person who wrote the post isn't the person who approves it.

It's basically the same habit I kept seeing in the survey, only with more people involved.

We build this at Publora — it's our workspace for agencies, and the API is documented here. I won't turn this into a tour of the product; if that's what you're looking for, the links are there.

What's been more interesting for me is realizing that some of the things we'd been thinking about as product features map almost exactly to things people told me they were worried about.

What I took from it

Automation is usually sold as: let the machine do this for you.

But after reading these replies, I think there's a pretty big group of people asking for something slightly different: help me do it, just don't take the whole thing away from me.

For someone posting to their own account, that might simply mean wanting to hit Publish themselves. For an agency, the same instinct turns into much more practical requirements: keep clients separate, don't pass passwords around, and make sure a person approves what goes out.

I find it slightly funny that it took working inside an automation company to make me think harder about what shouldn't be automated.

And for the record, I wrote this with AI. It helped me sort through material and clean up the draft. Deciding what was interesting in a few hundred replies was still my job.

I'm keeping that bit.

Where do you draw the line? What are you happy to hand to an agent, and what do you still want to do yourself?

I published our app on Zapier. The no-code platform made me write code.

Eugeniya Ivanova — Mon, 31 Aug 2026 06:29:04 +0000

Publora is in the Zapier app directory now. I didn't do it to tick a box on some distribution list. My job is making our product easy to live with, and if a user has an agent that can wire us in deeper so they don't have to build the plumbing themselves, I'll go make that happen. Zapier is exactly that case: it connects Publora to thousands of other apps, so nobody has to hand-roll the integration.

Worth it. I'd just add that "a no-code platform" and "publishing your own app on a no-code platform" turn out to be two very different Zapiers.

Prove it works for users who don't exist yet

Here's the requirement I reread three times, sure I'd misunderstood.

To submit an app for review, every trigger, every action, and every search has to be tested inside a live Zap, turned on, with at least one successful run in the history. You can't delete those Zaps; the reviewer can ask to see them.

So the logic goes like this. You want to publish an app so people can start using it. But to publish it, you first have to prove it's already being used. Run every component for real, as if you had the users you're publishing it to attract. The app isn't in the directory yet, and a history of real use already has to exist.

You end up standing in for your own users who aren't there yet. You build the Zaps, run each one, make sure every one has a green run, and don't touch them afterward.

A routine task you run like a rocket launch

The second surprise. My tasks here are the plain ones: schedule a post, publish a post, delete a post. This isn't a satellite launch. It's what our API does a thousand times a day over one line of code.

As a Zapier app, each of those ordinary tasks has to be wrapped, configured, and run live on its own. Create Post, Update Post, Delete Post, two triggers, two searches, each with its own test run under the validator's eye. Scheduling a post is something I can describe in one sentence. Here it became a component with a run history.

Then the small surprises a "no-code" promise doesn't quite imply. The connection label, the line that tells the user which account they connected, couldn't just read a field. {{connections.0.username}} doesn't work, because Zapier won't follow a path into an array. So the label needs actual JavaScript:

const connections = bundle.inputData.connections || [];
const first = connections[0] || {};
return { label: first.username || 'Publora' };

That's in a box labeled "label." On a no-code platform.

The triggers are the other place the word stretches. These aren't polling. They're REST Hooks on our own webhooks, which means subscribing and unsubscribing are API calls you define by hand:

// subscribe
const options = {
  url: 'https://api.publora.com/api/v1/webhooks',
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Accept': 'application/json',
    'x-publora-key': bundle.authData.api_key,
  },
  body: {
    name: 'Zapier - Post Published',
    url: bundle.targetUrl,
    events: ['post.published'],
  },
};

return z.request(options).then((response) => {
  response.throwForStatus();
  return response.json.webhook;
});

What subscribe returns is not incidental. Zapier hands it back to you as bundle.subscribeData, and unsubscribe reads the webhook id out of it to call DELETE /webhooks/{id}. Return the wrong shape and the Zap turns on cleanly, then never cleans up after itself.

A few more edges, for anyone about to do this. A field's type and key are locked after you create it, and if you get the shape of a step wrong and you don't fix it, you recreate it from scratch. The first published version gets locked for editing once real people are on it, so you clone it into a new one and make changes there. And the editor session expires with a cheerful failed csrf; you reload, and the code you just wrote is gone.

None of it is fatal. I just walked in with a one-line task and walked out with versioning, user migrations, and a chunk of JavaScript in a field called "label."

Where it landed

The app passed review after eight rounds of reviewer notes, then out into the directory with a Beta tag. Zapier's beta runs ninety days, and you leave it one of two ways: pull in enough active users, or embed their widget inside your own product. Familiar shape. The platform holds you at "not quite yet," and the key out is either bring it an audience or let it inside your product.

I don't regret the trip. The directory listing genuinely lowers the effort for anyone who wants to post from whatever workflow they already live in, and I wrote them a separate tutorial for that. But the "no-code" part I left somewhere around the halfway mark. For the user assembling a Zap out of ready-made blocks, sure, no code. For the person making those blocks, no-code ends exactly where anything past a single step begins.

For the record, I'm not an engineer. My job is getting people to use our product, and I built this with Claude: it wrote the code, I led, tested, and sent it back to redo. Which is maybe the honest shape of "no-code" in 2026 anyway. The code didn't disappear. It just moved to someone else, or something else.

Did your no-code platforms keep the promise when you went past a single step? Or did you end up opening the code editor too?

The agent posted successfully. To the wrong account.

Eugeniya Ivanova — Thu, 27 Aug 2026 08:31:54 +0000

Back in July I wrote about what it takes to wire an AI agent into social platforms: six OAuth flows, three-step media uploads, tokens expiring on their own private schedules. The conclusion was to hide all of it behind a single tool call and stop looking at it.

Two months on, that part is done. Our MCP server answers over OAuth now, with proper metadata at /.well-known/oauth-authorization-server, PKCE, and dynamic client registration, so connecting an editor no longer involves typing a key into a config file. Sixteen tools, one endpoint. The plumbing works.

What I got wrong was assuming the plumbing was the risky part.

My job is getting our product into people's hands, which means I use it the way I hope other people will: I ask an agent to publish and go back to what I was doing. Living with that for a couple of months taught me that once an agent has write access, failures stop announcing themselves.

An identifier that looks exactly like an identifier

A language model produces plausible-looking strings. That is the entire skill. Ask it to post to LinkedIn and it can hand the API a value with the right prefix, the right length, the right shape, and the wrong account.

Nothing about that request is malformed. There is no error to catch. The API was asked to do something specific and it did it.

So the first instruction our server gives any client is not a description of what it does. It's a rule: call list_connections first, copy each platformId verbatim, never invent one. Before the tool list, before the examples, before anything explaining what the product is for.

Writing documentation for a reader who will confidently improvise is a genuinely different job from writing it for a human who will get bored and skim.

"Tomorrow at 9am" is a timezone question

The API takes ISO 8601 in UTC and nothing else. So when you say "tomorrow at 9am," something has to decide which 9am you meant, and that something is the model.

It's right most of the time. When it isn't, nothing surfaces at the call. The response is a normal success, the post sits in the queue with a perfectly valid timestamp, and you find out at 4am from the post itself.

I now read the scheduled time back in the confirmation. Not because the model is bad at arithmetic, but because a wrong answer here is indistinguishable from a right one until it's too late to matter.

Accepted now, dead later

Instagram, TikTok and YouTube won't publish without media. Nothing stops an agent from scheduling a text-only Instagram post: it validates, it enters the queue, it sits there looking healthy for a day, and it dies at publish time.

Queue membership is not a promise. It's the kind of distinction you only learn by getting burned, because until then the failure is completely invisible.

The annotations nobody looks at

MCP lets a server tag each tool with hints about what it does: readOnlyHint, destructiveHint. Ours are filled in. Sixteen tools, six of them flagged destructive: deleting posts, deleting media, removing a LinkedIn comment or reaction.

{
  "name": "delete_post",
  "annotations": { "readOnlyHint": false, "destructiveHint": true }
}

They're advisory. A client can ignore them entirely, and plenty do. But they cost almost nothing to add, and they're the only way a server can tell a client "this one deserves a confirmation dialog" without inventing a private protocol. If you run an MCP server and haven't filled them in, that's twenty minutes of work that lets every well-behaved client protect your users for you.

A fake platform to post into

The fix I like most is the least clever one:

{ "content": "test", "platforms": ["publora-playground"] }

It accepts the post, validates it against the real rules, returns a normal response, and throws it away. Nothing reaches a real network.

It exists because there was previously no honest way to answer "is this connected and working?" Every genuine end-to-end test involved putting something real on someone's real timeline, which is a fine way to test at 2am and an awful one at any other hour. Now the whole round trip is testable without an audience.

Every integration that writes somewhere public should have one of these, and most don't.

What I'd tell July

I'm biased about the product, so here's the part that isn't about it.

When you give an agent write access to anything outward-facing, the failure worth designing against is not the 500. Exceptions land in logs and somebody eventually reads them. The dangerous one is the call that succeeds and quietly does the wrong thing: right shape, wrong target, no error anywhere in the chain.

The July version of this was "hide the complexity behind one tool call." I still think that's right. I'd just add the second half now: and make the tool call hard to get subtly wrong, because subtly wrong is the only kind of wrong that gets published.

Posting from the terminal saved me a context switch. The guardrails are what made me willing to leave it running while I did something else.

I drafted this with Claude and then checked every claim against the live server before publishing. The playground response, the tool annotations, and the OAuth metadata are all things I re-ran rather than remembered.

If you run an agent with write access to production, where's your line: a dry-run target, tool annotations, or a human confirming every call?

I built plugins for three editors. Everywhere, you're a guest in someone else's house

Eugeniya Ivanova — Wed, 26 Aug 2026 06:34:45 +0000

Over the last while I've built integrations for three places where people work with text and images: Obsidian, VS Code, and Figma. Doing a few of them back to back, I noticed something you don't see from a single one.

They're all desktop apps. For your integration to exist at all, the person first installs a program on their machine, and then, inside it, your plugin. You're not writing for the web. You're writing code locked inside someone else's app — and each app has its own runtime, its own rules, and its own wall for you to walk into. The web trained us to think an HTTP request is one line. Inside someone else's sandbox, it turns out even that has to be earned.

Figma was the strictest host of the three. I'll tell it through Figma, because it's locked down tighter than Obsidian or VS Code, and everything shows up on it at once.

The task was almost comically simple: select a frame, write a caption, pick your social accounts, publish — without exporting the image and opening a second app. We already had the publishing API, so I expected the Figma side to be small. And it was: the main plugin file is 120 lines. The work wasn't in them. It was around them.

Figma gives you bytes, not a file

The first version came together easily. When the selection changes, the plugin checks whether there's one exportable node and tells the UI what it found. For the preview it exports a small copy; for publishing, separately, at 2×.

const bytes = await nodes[0].exportAsync({
  format: "PNG",
  constraint: { type: "SCALE", value: 2 },
});

2× because the image still has a journey ahead of it: social networks recompress what you upload, and small text on a design goes noticeably softer by the time it lands in a feed.

Then the first quirk of the foreign house. Figma hands the plugin not a file but raw PNG bytes — exportAsync() returns a Uint8Array. Our normal API won't eat that — it doesn't take a giant image stuffed into a JSON body. It creates a post first, hands the client a temporary upload URL, waits for the file to reach storage, and only then attaches the media to the post.

So "publish one frame with a caption" turned into this:

create post → get upload URL → PUT PNG → complete media → update post

For a post with no image, it's one call. With an image, the post lives as a draft while the upload happens, and moves to its final state only once the media is there. That order saves you from a particularly annoying failure: scheduling a post, feeling pleased, then learning the image never uploaded.

Two worlds inside one plugin

A Figma plugin isn't one JavaScript. The main thread sees the document — that's where we read the selection and call exportAsync(). Network calls live in the UI, a separate context. Between them, a wall.

So the exported Uint8Array has to be thrown from the main thread over to the panel before anything can upload it. Convert it to a plain array, send it with postMessage, reassemble the bytes on the other side.

// main thread
const bytes = await exportSelection();

figma.ui.postMessage({
  type: "exported",
  bytes: Array.from(bytes),
});

// UI
exportedBytes = new Uint8Array(msg.bytes);

Not hard. Just one of those details that vanishes without a trace when you picture the feature in your head as "export the frame and send it to the API."

The next detail didn't let go so easily. The plugin UI runs in a sandboxed iframe with Origin: null. Our API, naturally, wasn't set up to accept browser requests from null — so the code worked right up to the point where it was supposed to do something useful. The classic: all green until it reaches the part that matters.

I ended up putting a small Cloudflare Worker between the plugin and the API. It forwards requests and adds the CORS headers Figma insists on. It doesn't store the key or add a second auth system — the key sits in figma.clientStorage and just gets passed through to Publora when the plugin makes a request.

We already had a similar worker for our Canva integration, but I made a separate one for Figma. Canva was on review at the time, and shipping new routes into infrastructure a reviewer might be poking at right then was a bad trade for saving one tiny worker.

A composer stops being simple very fast

Once the requests finally worked, the boring per-platform rules came back.

The plugin pulls the accounts already connected to Publora and shows them with usernames and avatars. You can pick several — which immediately raises the question of which limit the character counter should count against.

LinkedIn allows far more text than X. If both are checked, showing the LinkedIn limit is useless when X is going to reject the post anyway. So the counter uses the strictest limit among the selected networks.

function captionLimit() {
  const limits = [...selected]
    .map((id) => CAPTION_LIMITS[platformOf(id)])
    .filter((limit) => typeof limit === "number");

  return limits.length ? Math.min(...limits) : null;
}

Media works the same way. Publora won't take a text-only post for Instagram, TikTok, or YouTube. If one of those is selected and there isn't exactly one frame selected in Figma, the plugin says so and disables Publish instead of waiting for the API to object.

There are a handful of small cases like that in the UI. Two selected frames don't make two posts; the plugin asks you to pick one. A custom schedule time isn't valid until you've chosen a date. After a successful send, the form is replaced with a confirmation rather than leaving an active Publish button sitting there, a double post one impatient click away.

Nothing impressive in that code. It just took more time than getting exportAsync() to work.

And then you have to submit it

The other half of "make a Figma plugin" is making something Figma will actually list.

Because ours talks to an external service, the Community description says it outright: you need a Publora account, there's a free plan, the key is stored on the user's machine. Privacy policy and support contact are right there too.

The manifest has to be specific about network access. Ours lists the worker, Publora's media domain, and the storage hosts that receive the exported PNG. No wildcard for "whatever the upload API hands me next."

And we kept the listing strictly about what the plugin does in Figma. No stray product features, no mention of MCP. Figma has its own rules about MCP access to files, and it isn't needed here anyway: the plugin takes a design out of Figma and sends it where the user chose.

Before submitting, we ran the plugin in desktop Figma on a live Publora account. It connected, pulled the account list with its avatar, applied the LinkedIn limit, and created a real draft we confirmed through the API. The branch I trusted least was the image path — it crosses nearly every boundary in the plugin at once: Figma export, postMessage, the UI, the worker, the API, storage. That's the one I watched hardest.

It's on review now, so I don't have a tidy "and it was approved in six minutes" ending. Figma doesn't promise a fixed time either, so the last step of the build is glancing at the status occasionally and leaving it alone.

What it adds up to

The funny part is that the Figma-specific code really was small. Those 120 lines do almost exactly what I pictured at the start. What turned the feature into a project was everything between "I have PNG bytes" and "this can safely become a social post."

And it isn't only Figma. Obsidian made me go through its own requestUrl for network calls, because plain fetch hits the engine's limits on mobile. VS Code has its own ways. Figma has two contexts and Origin: null. Every time, you take the same task — "send a post" — and rewrite it for a different sandbox, because you're a guest in someone else's app, not at home on the web.

Whether it's worth it is a separate question. People work in these editors, and meeting them where they already are is more honest than dragging them over to you. But every one of those visits is a new runtime, a new wall, and a new worker to route around somebody's sandbox. I've done three, and I think I'm only starting to understand what I signed up for.

I built this plugin with Claude — it wrote most of the code. The decisions, the testing, and what to do at each wall were mine.

When your user lives inside someone else's desktop app, which way do you go: climb in there with them, or pull them out to the browser and into yours?

I shipped a plugin with one branch I hadn't tested — so I built a fallback

Eugeniya Ivanova — Thu, 20 Aug 2026 08:30:58 +0000

I wrote the Obsidian plugin with Claude Code: it typed the code; the rules, reviews, and decisions were mine. I led, argued with it, redid things, and submitted the plugin for review myself. I'm not an engineer. My job is getting people to actually use our product.

The plugin itself is simple: one main.js, 557 lines, zero dependencies, Obsidian API only. It takes the note you have open and sends it to your social accounts on a schedule.

Most of the evening, though, went into getting it through the Obsidian catalog. Here's what I tripped over, so hopefully you don't have to.

Six fixes the Obsidian review asked for

Before a plugin lands in the catalog, it gets reviewed against the Plugin guidelines. I read them beforehand and still came back with notes. Some requirements are much easier to notice once a reviewer points directly at them.

These were my six:

No innerHTML. Build the DOM with createEl. They check for this because innerHTML plus third-party text is an open door.
Styles go in styles.css, not inline in JS. Inline styles got bounced.
Modal titles use titleEl, not your own heading inside the modal.
No top-level heading in settings, and use sentence case, not Title Case Across Every Word.
Drop the plugin name from command titles. Obsidian adds the prefix itself; otherwise the command palette shows Publora: Publora: Send note. It stutters.
Network requests go through requestUrl. Plain fetch runs into problems on mobile, so if the plugin is isDesktopOnly: false, use Obsidian's API.

None of this changed what the plugin did. But doing it upfront would have saved me a review round and a couple of days.

A portal that won't explain its own errors

Submission goes through community.obsidian.md: sign in with your Obsidian account, then connect GitHub separately. The happy path is documented. The potholes aren't.

Mine:

"You do not own this repository" — when you clearly have access. If the repo belongs to an organization, choose the organization as the submission owner instead of Myself. The error disappeared immediately.

Your GitHub organization membership has to be public. The portal only sees public members. None of ours were public, so as far as the portal was concerned, our organization contained approximately nobody.

One request fixes your membership:

PUT /orgs/{org}/public_members/{username}

The catch: you can only make your own membership public this way. Each person has to do it with their own token.

The rate limiter. After several attempts, the portal starts replying with Please wait before trying again. It doesn't say how long, and clicking again only makes things worse.

The solution turned out to be extremely technical: leave it alone and come back later. Then click once.

Proving the release files came from your code

The review passed, but there was one note left: the release files had no artifact attestation.

If you haven't run into this before, the problem is pretty straightforward. Users don't install the source code they're looking at in your GitHub repository. They install the built main.js attached to a GitHub Release.

Those two files can be different.

Artifact attestation lets someone verify where the release file came from. GitHub Actions, through Sigstore, ties the artifact to a specific commit and workflow. This is the release.yml I ended up with — it also checks the tag matches the manifest version before it publishes:

name: Release

on:
  push:
    tags:
      - '*'

permissions:
  contents: write
  id-token: write
  attestations: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check the tag matches the manifest
        run: |
          tag="${GITHUB_REF_NAME}"
          manifest="$(node -p "require('./manifest.json').version")"
          if [ "$tag" != "$manifest" ]; then
            echo "Tag $tag does not match manifest version $manifest"
            exit 1
          fi

      - name: Attest the release assets
        uses: actions/attest-build-provenance@v2
        with:
          subject-path: |
            main.js
            manifest.json
            styles.css

      - name: Publish the release
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          gh release create "${GITHUB_REF_NAME}" \
            main.js manifest.json styles.css \
            --title "${GITHUB_REF_NAME}" \
            --generate-notes

The part that cost me the most time was these two permissions:

id-token: write
attestations: write

Without them, my workflow went green but no attestation appeared.

Everything looked fine. Everything was not fine.

Once I added the permissions, the check actually passed and verified GitHub artifact attestation showed up in the review.

This is probably my favorite part of the whole process: nobody has to take your word for it. The release itself carries proof of where it came from.

The branch I hadn't tested

At submission time, I still had one thing I hadn't managed to verify.

Login in the plugin goes through OAuth, so the user gets a token. Our REST API, meanwhile, had historically been used with an API key.

Would the API accept the token from this new OAuth flow?

Probably.

Had I actually tested it?

No.

I could ship it and find out from the first person whose button stopped working. People do this more often than conference talks would have you believe.

Instead, I built a fallback. The plugin sends the credential — whether that's the signed-in token or a pasted key — in the same x-publora-key header. If the request comes back 401 and the token was the one that failed, it retries once with the API key from settings instead of stranding the user mid-post. If there's no key to fall back to, it says so in plain words rather than leaving a dead button:

async function callApi(settings, method, path, body, plugin) {
  const credential = plugin ? await plugin.credential() : settings.apiKey;
  if (!credential) {
    throw new Error('Not connected yet. Open Settings, then Publora, and press Connect.');
  }

  const usedToken = Boolean(
    plugin && plugin.settings.oauth &&
    credential === plugin.settings.oauth.accessToken
  );

  const response = await requestUrl({
    url: BASE_URL + path,
    method,
    headers: { 'x-publora-key': credential, 'Content-Type': 'application/json' },
    body: body ? JSON.stringify(body) : undefined,
    throw: false,
  });

  if (response.status === 401) {
    // The signed-in token was refused. If a key is also configured, use it
    // rather than stranding the user mid-post.
    if (usedToken && settings.apiKey) {
      return callApi(Object.assign({}, settings, { oauth: null }), method, path, body, null);
    }
    throw new Error(
      usedToken
        ? 'Publora refused the signed-in account. Reconnect in Settings → Publora, or paste an API key there under Advanced.'
        : 'Publora rejected the API key. Check it in Settings → Publora.',
    );
  }

  return response.json;
}

The retry is just the same function calling itself with oauth nulled out, so it falls through to the key. A week later, working on OAuth for another add-on, I finally got to test the real thing: the REST API accepts the token fine, and the fallback never fired.

But I didn't know that when I submitted the plugin.

That's the bit I want to keep from this whole exercise. Sometimes you have a branch you can't test before release. You don't have to pretend otherwise. If the failure mode is predictable and the fallback is cheap, you can put the uncertainty into the program instead of handing it to the user.

Numbers I actually trust

As of August 19: 33 installs.

Not a lot.

But the version distribution shows most of those installs on the latest version, so people are updating rather than installing once and disappearing.

For comparison, our extension on another marketplace shows 772 "downloads." That counter also eats mirrors and editor caches. At one point it jumped by 26 in half an hour when basically nobody knew the extension existed.

So right now I'll take the 33.

At least I know what they mean.

I built this plugin with AI, and I'm not particularly interested in hiding that. Claude Code typed most of it. I decided what it should do, reviewed what it produced, dealt with the submission, and decided what to do when I couldn't verify something before release.

The typing is increasingly the easy part.

The annoying part is still noticing the thing you haven't tested.

What do you do when you reach release with one branch still uncertain: ship it and wait for the bug report, or build the fallback first?

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?