Steady comes up a lot. It is a membership platform from Berlin, and a great many German-speaking publishers and podcasters run their memberships on it. It takes the money side off the publisher’s desk: it handles the payments and the VAT, and it pays out. Readers sign up and pay at Steady, and the publisher gates content with the Steady Widget, Steady’s own paywall script, or with an embed.
Several PayGlue customers and prospects have asked for it, so at the end of August I started the evaluation. This article is the result. PayGlue will not connect Steady, and I want to write down why, because the reason is not that Steady is bad.
What I asked Steady, and what came back
I wrote to Steady’s support with four questions. Does Steady send webhooks for subscription events? Are there rate limits on the API? Is there a sandbox, a test publication where I can run purchases without real money? And is there a partner programme for integrations like this one?
I got two replies. Both came from Steady’s AI support agent. A person never joined in. Paraphrased, the agent said this: there is no webhook endpoint for subscription events. The events themselves exist. New membership, trial becomes paid, cancellation, expiry, plan change, member data change. But you can only get at them as Zapier triggers. On rate limits, on a sandbox and on a partner programme the agent had no information, and it pointed me at developers.steadyhq.com.
So I read developers.steadyhq.com from start to finish. It did not take long.
What the docs actually offer
There is a publication-scoped REST API, authenticated with an API key and shaped as JSON:API. It gives you the publication, its plans, a list of all current subscriptions, a way to cancel a subscription, the newsletter subscribers and the posts. That is a reasonable API for a publisher’s own tooling, and I have no complaint about it.
There is also an OAuth 2.0 flow for readers with two endpoints: the current user and the current subscription, with refresh tokens. If you send a reader through the authorize link to the Steady campaign page and they subscribe there, they come back to your app authorized. That is how you would build a “log in with Steady” button.
What the docs do not have is any mention of webhooks, rate limits or a test environment. The AI agent was right about that. And there is a warning I did not expect: the Steady Widget runs its own client-side OAuth flow, and if you run a second OAuth flow on the same page, the two login states get out of sync. I read that paragraph twice, because it comes back later.
What PayGlue needs from a provider
PayGlue’s whole job is to turn a purchase at a provider into a member in the publisher’s Ghost, and to take that access away again when the subscription ends. For that it needs one thing from the provider: the provider has to tell PayGlue when something happens. A purchase, an activation, a cancellation, an expiry, a plan change. The provider calls a URL with a signed payload, PayGlue verifies the signature and updates the Ghost member. And it needs a way to test all of that without real money, because I am not going to buy a subscription every time I touch the code.
That is how Polar, Lemon Squeezy, PayPal, Gumroad, Paddle, Ko-fi, Creem and Patreon work. Patreon is the closest comparison to Steady: also a membership platform with its own audience and its own idea of who the member is. But Patreon publishes webhooks for pledge create, update and delete, so patrons become Ghost members without anyone polling anything.
I keep using the word honest, and I mean it literally. If PayGlue grants access on Monday and only finds out on Thursday that the reader cancelled on Tuesday, then for three days the paywall was wrong, and neither the publisher nor the reader knew.
Three ways around it, and why I rejected each
There are three usual ways around a missing webhook, and I went through each of them before I let myself say no.
Zapier as a bridge came first. The publisher builds a Zap that takes the Steady triggers and posts them to a PayGlue endpoint. This works today. But it needs a paid Zapier account per publisher, every event costs a task, and when the Zap breaks, the error handling sits with the publisher. I would be selling a connection that depends on a third tool the publisher has to babysit, and the first support ticket would be about that tool, not about PayGlue.
Polling came second. PayGlue fetches Steady’s subscription list every few minutes and diffs it against the last run. Then the load is on my side, every failure mode is on my side, and a change that happens and reverses between two polls is lost. I do not want to run that, and I do not want to explain to a publisher why a reader had access for four minutes that they should not have had.
The third was “log in with Steady” at the PayGlue paywall, using the OAuth flow, plus a re-check at the subscription’s expiry date. The reader clicks, goes to Steady and comes back authorized, and now PayGlue knows their subscription. This one is technically sound and the closest to working, and I liked it for a while. But it puts an extra login step in front of every reader at every site, and PayGlue does not have enough readers behind it yet to ask that of them. It also collides with the Steady Widget on the same page, which is exactly the situation the docs warn about.
The decision
PayGlue does not connect Steady. It goes into the same category as Mollie in July, where the API was built for e-commerce and the recurring model asked each merchant to build their own subscription logic. In both cases the platform is fine for what it was built for. In both cases the piece I need is missing, and I cannot add it from the outside.
This is not a judgement on Steady. For a publisher who wants to live in Steady’s ecosystem, with Steady’s checkout and Steady’s audience, it is a good choice, and Whose Member Is It explains the trade you make when you choose it. I can only treat a reader as a Ghost member for as long as something tells me they still are one, and with Steady nothing does.
Two things would change the decision: a documented webhook endpoint with a signature on the payload, and a test publication. If Steady ships those, I will build the connection, and the evaluation is already done. Until then the changelog carries Steady as won’t build, next to the other things I looked at and put down. If the docs grow a webhooks page before I notice, tell me. I will read it the same day.