DEV Community: Eugeniya Ivanova

The portal said "Live." For a few hours the page kept saying the connector didn't exist.

Eugeniya Ivanova — Thu, 24 Sep 2026 07:49:57 +0000

I've submitted to just about every directory I could reach by now. Chrome, Firefox, Edge, Zapier, IFTTT, Figma, ChatGPT. Every time it's someone else's place: you show up, they check what you've brought, sometimes they send you back to fix it, sometimes they let you in. I've written enough about review rounds and strange submission rules by now.

And this week we submitted Publora to the official Claude connectors directory. For some reason I'd been preparing for this one longer than any of the others. Not technically. The work was done. Apparently I had some feelings left over.

Fifteen minutes I'd been walking toward the longest

The submission itself took about fifteen minutes. A form, a button, done. Submitted yesterday, in the directory today. Behind those fifteen minutes was a month and a half of work by the whole team: thirteen pages of Anthropic documentation, checking the server against fifteen requirements with live requests, and manually running all eighteen tools against production.

So why did the easiest submission bother me more than some of the genuinely horrible ones?

I think it's because all the previous directories felt like other people's territory. Claude doesn't. I'm not an engineer; my job is getting people to use our product, and almost everything I've built this year I've built with Claude somewhere next to me. It's my pocket techie: it writes the code, I lead, argue and make it redo things. Twenty articles, a dozen and a half integrations, all those submissions. And now Publora is sitting in Claude's own directory. That felt different.

That's enough sentiment. There were also several stupid things that cost us time, and those are probably more useful if you're submitting a connector yourself.

The portal says one thing, reality says another

The main thing I'd keep in mind: a green status in the portal doesn't necessarily mean the thing next to it is already working. We found that out in three different places.

"Live in the directory," and the page is empty. We hit publish and the portal immediately reported "live." The listing page, meanwhile, spent several hours returning "This connector doesn't exist." The View listing button went to the same page, and search found only our temporary connection. We'd already written a support email and, luckily, hadn't sent it yet. A few hours later the listing appeared on its own. If you see the same thing, give it some time before writing to support.

The portal decides the server is authless when it isn't. At the authorization step it checks tools/list. Ours returns the tool list without a token, so the portal announced: "Server requires no auth to list and call tools." The first half is true. The second isn't. You can see our tools without authorization, but you can't call any of them. We still had to select OAuth manually.

The docs disagreed with the live form in four places. The docs promised eleven steps; we got ten. The icon field was described as a file upload but turned out to want a URL. The best one was the listing address: the docs use claude.ai/directory/connectors/<slug>, while the actual listing is claude.ai/directory/<slug>. The old version even appeared in the approval email. We nearly copied it into our own documentation because apparently an email can still outrank the browser in my head.

The rake half the ecosystem steps on

One deserves its own section, because I went looking to see whether we'd done something stupid. This time, at least, we had company.

The portal flagged all eighteen of our tools as "missing a title." All eighteen had titles. The problem is that the MCP spec has two places for title: top-level Tool.title, added in summer 2025, and the older annotations.title. We used the newer field. The Claude directory was checking annotations.title.

This has caught other people too. A pull request to FastMCP describes the same problem: its titles were going only into the top-level field, so the Claude connectors directory saw the tools as nameless. If the portal says your tools are missing titles and you can clearly see the titles in the schema, check annotations.title before doing anything more dramatic. That string is also what users see in the confirmation dialog, so they get "Create post" instead of create_post.

A couple of smaller rakes, also worth taking with you

The form draft doesn't save. We went through all ten steps, clicked "Save and exit," and lost the lot. When we came back, the form was empty and the dashboard said we hadn't submitted any servers. "Draft saved in this tab" is apparently very literal. I'd do the form in one sitting.

The "Keep your personal account separate" checkbox when creating an organization. Without it, your personal subscription is cancelled and your chat history moves into the organization, with no way to move it back. It's an easy checkbox to skim past and not a particularly easy decision to undo.

About what I learned myself

Separately, because this part was my problem rather than Anthropic's. Along the way I put four things into our blockers: a network supposedly missing from the test account, a strange 403, dead tokens and a parameter I thought we had to change. None survived an actual live check. In several cases I'd looked at one field in the database, decided what it meant and promoted the guess to a problem.

There was a good example in the other direction too. At one point I entered the wrong plan, the one I thought was required for submission. Claude accepted that as a fact, built the rest of the reasoning around it and very confidently helped me proceed in the wrong direction. Which was fair enough. I had given it bad information and then asked it to reason from there.

I'm getting better at noticing this when we work together: when Claude has started building on an assumption, when it's doing something I didn't actually ask for, and when I need to stop and check the boring fact underneath all the reasoning. The same applies to me. My "I think there's a defect here" can become a blocker in a document surprisingly quickly. Claude's guess can do the same. Neither becomes more factual because it has been written down neatly.

What to do with this yourself

Publora is in the Claude directory now. You can connect it and create posts for ten social networks from the same chat where you're already working, instead of moving the text into another app afterward.

The part I'd still be careful with is delegation. I've written about this before, but it keeps coming up: vague instructions give Claude room to fill things in. If you want a post published, tell it what to publish, where and when. If you want a draft, say draft. I don't rely on Claude to guess which parts of a publishing decision I meant to leave unsaid.

Looking back at the things I've built this year, there's a slightly ridiculous amount of technical work for someone who still introduces herself by saying she's not an engineer. Claude has been involved in most of it. So seeing Publora in its directory was nice in a way I hadn't expected.

The actual submission took fifteen minutes. Getting to the point where those fifteen minutes were possible took considerably longer.

I wrote this one with Claude as well, which seemed only fair given where it ended up. I told it what happened, it drafted, and I cut whatever hadn't actually happened.

Have you ever spent months getting somewhere and then found the actual moment itself was almost suspiciously uneventful?

I was sure Figma would reject my cover art. The email asked about something else.

Eugeniya Ivanova — Mon, 21 Sep 2026 07:32:45 +0000

A few years ago, my Figma skills were roughly limited to whatever I could make from templates designer friends gave me. Sometimes I made silly pictures for colleagues. A normal user, basically: I can do a few things, and if I can't, I probably don't need to be there.

Then I changed jobs, and somehow this escalated. Sometimes I fix a layout myself, sometimes I make an agent do it because spending half an hour figuring out where Figma hid one particular effect is usually beyond both my time and my patience. And then I ended up in a fairly strange place: I wasn't just using other people's Figma plugins anymore. I'd made my own. It lets you send a design from Figma straight to your social accounts without exporting it and dragging it through three other apps first.

What a wonderful world. You never know where it'll take you.

Where I got stuck, and it wasn't where I expected

Writing the plugin wasn't the scary part. I got stuck on the pictures.

To publish a plugin, Figma asks for an icon, a cover and screenshots. The cover stopped me. Make it myself in Figma, where I am, let's put it gently, not very good? Give it to an agent? Do both and then spend ages choosing between things I'm not qualified to judge? I spent an embarrassing amount of time on this.

The problem was stupid, but real. I was about to submit a plugin to a platform full of designers. Actual designers. And here I come with my cover. People will look at it. People will know.

In the end, Claude made the cover. Simple, clean, no attempt on my part to demonstrate the designer apparently hiding somewhere inside me. I submitted the plugin and waited to be told what was wrong with the pictures.

The email came. About something else.

Figma's review was nothing like the others I'd been through. Chrome took two rounds. Adobe sent us back with changes too. Zapier had eight. By then I'd come to think of moderation as a kind of correspondence where somebody explains what you've done wrong and you write back when you've fixed it.

Figma said nothing. Then an email arrived: send us a video showing how the plugin works.

That was it.

Not "the cover is weak." Not "the icon needs work." Not even "who let you in here." They wanted to see that the plugin did what it was supposed to do.

We recorded the video and sent it. Silence again. Then the plugin appeared in the Community. It even has a couple of users already, which I particularly like because it means we're no longer the only people using the thing we made.

Only after that did I read Figma's review rules, which would obviously have been more useful before I started worrying. There's nothing in there about how the cover looks. They review whether the plugin is finished, whether it crashes, whether it does what the listing says, whether it's safe with someone's files. The only line that touches the pictures at all asks for an accurate description, screenshot, or previews, "so that the users will not be surprised by any hidden functionality." Not a good cover. An honest one.

So I'd spent several days worrying about a test nobody was planning to give me.

And this is where it gets a little strange

I didn't become a designer along the way. I didn't become an engineer either. But there's a plugin in the Figma Community now, and it has a perfectly decent cover.

A few years ago, "make a cover for a plugin" would have meant learning how to make covers first. Now I can explain what I need to an agent, get a few options, throw away the terrible ones and keep something decent. This does not make me a designer. It does, however, leave me with a cover.

I'm still not entirely sure what I think about that. Taste and a good eye obviously still matter: if you're given five bad options, somebody has to notice they're bad. But I also quite like living in a world where needing one particular effect doesn't automatically mean watching a forty-minute tutorial about it.

My actual job is getting people to use our product. I'm not a designer or an engineer. But somewhere in the Figma Community there's now our plugin, with a cover I couldn't have made myself.

Well. Apparently I can make Figma plugins now.

I wrote this one with Claude too, which feels about right for a post that's partly about not making things myself. I described what happened, it drafted, and I cut the parts that weren't true.

Has AI ever dropped you somewhere the old rules say you don't belong?

I didn't come to Claude through code. I came through a 10 a.m. routine.

Eugeniya Ivanova — Fri, 18 Sep 2026 07:28:48 +0000

Most people I know got to Claude through code, which is reasonable enough considering the name. I got there because at ten in the morning I wanted somebody else to check my numbers.

I'm not an engineer. My job is getting people to use our product, which means I spend a surprising amount of time looking at numbers, looking at people, and then looking at the numbers again because I no longer trust what I saw the first time. I started with Claude Desktop, then tried Cowork, and eventually found routines. I have three now. None is particularly impressive, which is probably why I actually use them.

The 10 a.m. check

The serious Publora analytics live in Claude Code in VSCode. That's where the keys are, the detailed data, revenue, and all the things capable of ruining an otherwise decent morning. I can go in there and dig properly, but the problem is that I can always dig properly. There is always another cohort to check, another strange number, another question that suddenly seems urgent because I've opened the file containing it. If I do that every morning, there goes the morning.

So at 10 a.m. Claude sends me a Publora brief: tasks, analytics, meetings, anything that looks unusual. I've normally been at my desk since eight, so by then I've had coffee, answered email and acquired enough emotional stability to look at analytics. If something moved, I open VSCode and investigate. If everything looks normal, I leave it alone. Before this routine, apparently I needed two hours of analysis every now and then to discover that everything was fine.

The file where future posts go to wait

The second routine runs Monday, Wednesday and Friday. It looks around my usual topics, finds two or three things worth writing about and puts them in content-backlog.md.

The file turned out to matter. At first I had Claude send me ideas, which produced a very nice list that I would read, approve of and never see again. Now the ideas accumulate in one place. By Friday there are several possible posts in there. Some are bad, some seemed good on Monday and make no sense by Friday, and usually a couple survive.

That's all I need from it. I don't want Claude writing my posts while I sleep. I want to sit down to write and not spend the first forty minutes discovering that apparently I have never had a thought in my life.

Hacker News without going to Hacker News

The third one is technically a scheduled task rather than a routine. It gives me a Hacker News digest twice a day. This exists because I know what happens when I tell myself I'll check the news when I have time: either I don't, or I open Hacker News to read one thing, then another, then somebody is wrong in the comments, and forty minutes later I'm extremely well informed about something I wasn't working on.

Now the digest arrives by itself. I skim it, open whatever actually looks useful and occasionally find something I want to comment on. I remain approximately aware of the world without having to visit quite so much of it.

My routines stop when I close the laptop

There is one limitation: these routines are local, so my computer has to be awake and online. Claude Code also has cloud Routines that can run while the laptop is closed, which means you can wake up and the work is already there. People quite reasonably describe this as an advantage.

I understand them intellectually. Personally, I'm an anxious person, and the idea that Claude has been awake since six doing things on my behalf while I was asleep does not relax me. I'd wake up wondering what it had done. Mine start working when I do. I'm at the desk, Claude is at the desk, and nobody has been getting creative overnight. This arrangement suits me.

What I actually gave it

None of these routines does anything spectacular. One checks whether something in the numbers needs my attention, one keeps a file of things I might write about, and one reads Hacker News so I don't accidentally spend forty minutes reading Hacker News myself.

I still make the decisions, which unfortunately seems to be most of my job. What disappeared was the need to remember to go and check all this stuff myself. And I set the whole thing up in plain English, without writing code, which is mildly funny considering how long the word "Code" made me assume this wasn't for me.

Now I'm much more interested in the boring things people put on routines than the impressive ones.

I wrote this one with Claude as well: I described what the three routines actually do, it drafted, and I cut the parts that weren't true. Which is more or less the arrangement everywhere else in this post.

What's the stupid recurring thing you got tired of doing yourself?

IFTTT accepted our service on the first try. The flow broke on the first redirect.

Eugeniya Ivanova — Wed, 16 Sep 2026 15:30:00 +0000

Last week I was bringing Publora onto IFTTT. Our server was already live, OAuth was working, and the API was there. I expected most of the work to be filling in their application and getting through review.

The application passed on the first try, in under a day instead of the estimated one to two weeks. The actual integration broke on the first authorization redirect.

Here's what I ran into.

The OAuth that didn't line up

The first problem showed up immediately.

IFTTT sends plain OAuth2: authorization code, no PKCE. Our authorization server requires PKCE. Their redirect arrives without a code_challenge, so our server rejects it.

I tried the request in exactly the format IFTTT sends:

GET https://mcp.publora.com/authorize
  ?client_id=...&response_type=code&scope=ifttt&state=...&redirect_uri=...

-> 302 ...?error=invalid_request
   "expected string, received undefined" on code_challenge

Add a code_challenge to the same request and it reaches the login screen normally. So there wasn't much mystery left: IFTTT doesn't send something our authorization server requires.

I could either make PKCE optional on our server for IFTTT or put something between the two. I went with the second option.

I added a small Cloudflare Worker between IFTTT and Publora. To IFTTT, it looks like the plain OAuth2 provider it expects: no PKCE and a non-expiring token. On the Publora side, the Worker runs the PKCE flow itself, generating the verifier and challenge before sending the request to our authorization server.

That also gave me somewhere to handle the rest of the differences between the two APIs. IFTTT expects endpoints and responses in its own format, while Publora already has its own API. The Worker translates between them.

Turning posts into an event feed

IFTTT treats a trigger as a feed rather than a current state: up to fifty recent events, newest first, each with its own meta.id and meta.timestamp in seconds.

For Publora that means one post group may need to become several events, one for each channel. Otherwise the meta.id isn't unique:

for (const post of posts) {
  for (const target of post.platforms ?? []) {
    items.push({
      content: post.content,
      account: label(connections, target.platformId),
      network: target.platform,
      occurred_at: at,
      meta: { id: `${post.postGroupId}:${target.platformId}`, timestamp: seconds(at) },
    });
  }
}

There's another requirement they test separately: every trigger needs to return at least three events during testing, so it behaves like a feed rather than a state sensor. An empty or short response doesn't pass.

I also replaced hourly polling with realtime notifications. A Publora webhook is created when the connection is set up, and when an event arrives the Worker calls IFTTT's Realtime API. It doesn't send the event data there; it just tells IFTTT there's something new, and IFTTT fetches the feed itself.

Five things I couldn't find in their docs

This is where I spent most of the time. If you're building an IFTTT service, these are worth knowing before you start running their tests.

The test/setup endpoint is required, but I couldn't find it in the docs. Their automated tests hit it second. There is a sample response in the dashboard under View scaffold JSON: it needs a queries section, and media_url can't be an empty string. The method isn't specified there, so ours accepts both GET and POST.

Ingredient slugs can double without showing it in the UI. The form generates a slug while you're typing the field name, and entering your own can leave you with things like contentcontent and occurred_atoccurred_at. The resulting slug isn't visible in the form. I only found it in the service export under Tools, Export. A good chunk of my failed tests came from this.

The UI didn't show me why tests were failing. I could expand the failed result row, but it was empty. The actual results were available through these endpoints:

POST /services/<slug>/publish/endpoint_session   -> session_id
GET  /services/<slug>/publish/endpoint_test_results?offset=N&session_id=...

The results come in chunks, with suite_end marking the end. That's where I eventually found the individual failed checks.

A request with no fields needs to return a proper 400. They test requests with triggerFields missing and with required keys missing inside it. The response needs an errors array. I initially supplied defaults in some of these cases, which made the tests fail.

The cursor is mandatory when results are limited. If you return only part of the feed because of a limit, the response also needs a cursor. Without it, the test fails.

Numbers

Their run has 535 checks. I eventually got it to zero failures, after spending considerably more time than I'd like to admit on doubled slugs and test results hidden behind an empty UI row.

There are also two launch requirements I hadn't found in the docs: twelve published applets and four service admins. You can submit the service without them, but you need them before launch.

I submitted on September 7 and the review passed on September 8, so under a day against the estimated one to two weeks.

The Worker ended up at about 700 lines of TypeScript and a 19.8 KB bundle.

What I'd check first next time

If you're doing an IFTTT integration, check the generated slugs in the service export rather than trusting the form. If an automated test fails without an explanation in the UI, look at endpoint_test_results. And before running the full suite, make sure you have test/setup, cursors on limited responses, and proper 400 responses for missing fields.

For OAuth, I was glad I didn't make PKCE optional in Publora just to accommodate this integration. The Worker was already needed to translate IFTTT's API format, so handling the OAuth difference there kept the change isolated too.

I built it with Claude: it wrote most of the TypeScript, while I tested the requests in IFTTT's format and worked out where the two sides disagreed. Most of the time went into finding those disagreements, especially the ones I couldn't see from the dashboard.

The listing is here: https://ifttt.com/publora

If you've integrated with IFTTT before and found another undocumented test, I'd like to know which one.

I gave an agent my posting history. It found a promise I never made.

Eugeniya Ivanova — Tue, 08 Sep 2026 07:10:41 +0000

Every social platform rewards the same thing, and it isn't a secret: showing up regularly. The hard part isn't writing. It's deciding what to say today, and on plenty of days there either isn't an answer or you don't feel like hunting for one.

Someone I was talking to on LinkedIn last week told me they stick with their scheduling tool mostly because of the post templates. When they run out of ideas, the templates give them somewhere to start. That surprised me. I would have guessed people got stuck on the writing, not on choosing the topic.

Asking an agent doesn't really fix that either, at least not in the usual setup. You say "write me a post," it gives you one draft based on its first guess, and if you're not convinced, there's often nothing specific to react to. You end up rewriting it yourself, which rather defeats the point.

So this week I built a small skill around one very narrow idea: don't give me a draft first. Give me three angles and let me pick. Three options I can answer with a number.

It works now. The first real run didn't. It failed three times before it gave me anything useful, and all three failures came from the same place: the agent was reading my own data and treating its interpretation as fact.

It read my test posts as things my audience saw

The skill starts by calling list_posts and reading the last twenty. It's looking for two things: topics I've already covered, so it doesn't suggest the same thing again, and threads I've left hanging. A launch with no follow-up. A question I asked and never came back to. Those are often more useful than inventing a new topic because the context already exists and I usually have the material.

It found one. Two posts on my LinkedIn from late July said Publora was coming to Zapier. Nothing after that. So it suggested: finish the thread, you promised this a month ago and never said how it turned out.

Except I hadn't promised anything.

Those posts were Zapier review artifacts. To submit an app there, you have to run every trigger and action inside a live Zap, switch it on, and leave a successful run in the history. That means my account contains posts with names like Zapier validation — update target. They look like normal posts in the same list, and the agent had no idea they weren't meant for an audience.

I added a filter: short posts, near-duplicates minutes apart, anything containing test or validation. But the more useful fix was a rule:

Never state an inference from history as a fact.

"You promised X and never followed up" sounds confident, but it's still an inference from a list that includes QA junk. The agent should say what it found and ask whether it understood it correctly. Once I corrected it, the whole session changed direction in one message. If I hadn't noticed, I could easily have published a post referring to a promise nobody ever saw.

It could only see what went through the product

Once we had the right angle, the skill asked for the one fact it couldn't know: what actually happened with Zapier. I told it we were live but still in beta.

What it didn't ask was whether I'd already written about it somewhere else. I had. That morning I'd published a four-minute Dev.to article with the eight rounds of review, the REST Hooks, and the JavaScript I ended up putting in a field labeled "label". None of that existed in Publora, so the skill had no way to know about it.

That limitation is obvious in theory: an agent only knows the data you give it. In practice, it's easy to forget until it starts repeating something you've already published elsewhere.

So now, whenever it asks for a missing fact, it also asks whether I've already written about the topic somewhere else: article, changelog, release notes, whatever.

The slop checker passed a draft that was still slop

I run every outgoing text through a script that flags machine-sounding writing: vocabulary, repeated structures, the usual tells that become easy to spot once you've collected enough of them.

The draft passed.

I showed it to a colleague anyway, and she said she could still see AI slop in it. She was right.

Three of the strongest lines had been lifted almost directly from my Dev.to article from that morning. "The requirement I reread three times, certain I'd misunderstood." Fine line on its own. Less fine when the same person has already seen it six hours earlier. No vocabulary checker is going to catch that.

The other problems were structural. A withheld hook: "with a Beta tag, which I'll get to." A neat paradox: "you have to prove the app is being used before it's allowed to exist." A three-item list whose last item worked mostly because of the rhythm. The word "literally". None of those is automatically bad. Together, in a short post, they started sounding very familiar.

The rewrite was 720 characters. The version that passed the script was 1198.

So I kept the checker, but moved it earlier in the process. It catches the things that exist inside the text. What it can't see is everything around the text: what I published yesterday, who is reading, or whether I've stacked too many individually reasonable choices into something that sounds generated.

I'd still put a checker somewhere between draft and publish. It costs very little once it exists, catches the obvious layer, and doesn't get tired at six in the evening. Build one, borrow one, or use a checklist. Just don't mistake it for the whole review.

What it looks like now

There are eight categories and forty angles. Every angle has a core: one fact that has to come from the person using the skill, whether that's the mistake, the number, or the tool name. The instructions repeat this in several places because inventing that core is the easiest way to produce something plausible and false under someone's name.

There are also four reference files behind the angles: what the first two lines need to do before the feed collapses the rest, how to infer voice from existing posts instead of asking someone to describe their own voice, the tells a script can't catch, and how the same angle changes between LinkedIn and X.

It stops at the draft. Nothing publishes automatically.

It's MIT, it works on its own, and connecting Publora lets it read your feed and schedule the result: publora-team/publora-post-ideas

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 when it got things wrong. Most of the useful work ended up being in those three failures, because each one showed me a rule I hadn't written yet.

Has an agent ever been confidently wrong about your own data? I'm curious what it misunderstood, and what you changed after that.

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?