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.
