Forem: Anand Rathnas

Why We Removed Ads from Our Free Tools (And Put Them Only on Blog Posts)

Anand Rathnas — Tue, 12 May 2026 01:36:44 +0000

We built a suite of free developer tools: JSON formatter, JWT decoder, QR generator, UTM builder, and about a dozen others.

Then we added AdSense to every page.

Then we removed it from most of them.

Here's why.

The Original Plan

The logic seemed sound:

Free tools bring traffic (SEO)
Traffic sees ads
Ads generate revenue
Revenue funds development

We added a simple <AdSlot /> component to our UtilityPageLayout:

// Before: Ad on every utility page
export function UtilityPageLayout({ children }) {
  return (
    <main>
      <AdSlot position="top" />
      {children}
      <AdSlot position="bottom" />
    </main>
  );
}

Every tool page now had ads at the top and bottom.

What Actually Happened

Week 1: Impressions up, RPM decent.

Week 2: Noticed something odd in analytics.

Users on utility pages had:

Higher bounce rate (+15%)
Lower time on site (-20%)
Fewer conversions to signup (-25%)

The ads were working as ads. They were also working as exit doors.

The Problem with Ads on Utility Pages

Utility pages have a specific user intent: Do one thing, leave.

Someone using a JSON formatter:

Pastes JSON
Gets formatted output
Copies it
Leaves

Total time on page: 30 seconds.

An ad in this flow is a distraction. Worse, it's a competing call-to-action. The user came to format JSON. The ad says "Hey, check out this other thing."

If they click the ad, they leave. If they don't click the ad, it just... sits there, making the page feel cluttered.

Blog Posts Are Different

Blog posts have a different user intent: Learn something.

Someone reading a blog post:

Searches for a problem
Reads the solution
Maybe reads related sections
Considers the author's credibility
Might explore more content

Total time on page: 3-5 minutes.

An ad in this flow is... fine. The user is already in "reading mode." They're not trying to complete a task. A well-placed ad between sections doesn't interrupt a workflow because there's no workflow to interrupt.

The Fix

We removed ads from utility pages entirely:

// After: No ads in UtilityPageLayout
export function UtilityPageLayout({ children }) {
  return (
    <main>
      {children}
    </main>
  );
}

And kept them only on blog posts:

<!-- posts template -->
<article class="blog-post">
  <header>...</header>

  <div class="ad-container ad-top">
    <!-- Ad after title, before content -->
  </div>

  <div class="post-content">
    {{ content }}
  </div>

  <div class="ad-container ad-bottom">
    <!-- Ad after content, before footer -->
  </div>

  <footer>...</footer>
</article>

The Results

After removing ads from utility pages:

Bounce rate: Back to baseline
Time on site: +10% (people explored more)
Signups from utility pages: +30%

Ad revenue from blog posts alone: About the same (blog traffic is smaller but more engaged)

Net effect: More signups, same ad revenue.

The Principle

Match monetization to intent.

Page Type	User Intent	Monetization
Utility tools	Complete task quickly	None (or subtle "Made by X")
Blog posts	Learn, explore	Ads okay
Landing pages	Evaluate product	None (focus on conversion)
Documentation	Find answer	None (builds trust)

Ads work when they don't compete with the page's purpose. On a blog post, the purpose is consumption. On a utility page, the purpose is production.

What We Do Instead on Utility Pages

Instead of ads, utility pages now have:

Subtle branding: "Built by jo4.io" in the footer
Relevant CTAs: "Need to track these links? Try jo4.io" on the UTM builder
Cross-links: "You might also like: QR Generator, Link Shortener"

These don't generate direct ad revenue, but they:

Keep users in our ecosystem
Build brand recognition
Convert better than ads ever did

The Takeaway

Free tools are marketing, not monetization.

The ROI of a free JSON formatter isn't the $0.03 per ad click. It's the developer who bookmarks it, uses it weekly, and eventually needs a URL shortener for their project.

Ads on utility pages optimize for the wrong metric.

Do you run ads on your free tools? Curious how others handle this tradeoff.

Building jo4.io - free developer tools that won't interrupt your workflow.

The Auth0 Pricing Trap: Why Upgrading to Paid Gives You Less

Anand Rathnas — Sat, 09 May 2026 01:35:57 +0000

I was about to upgrade our Auth0 plan to get a cleaner domain. Then I looked at the pricing page.

And closed the tab.

The Setup

Auth0 gives you a randomly generated tenant URL when you sign up:

dev-exjsxdx8c6qt3uhf.us.auth0.com

Not exactly brand-inspiring. I wanted something cleaner like jo4.us.auth0.com.

To get a custom tenant name, you need to create a new tenant. To create a new tenant on the free plan:

❌ You have reached the limit for Tenants in your current plan.
   Upgrade your plan to create more tenants.

Fine, I thought. What does the paid plan cost?

The Math That Doesn't Math

Free Plan:

25,000 MAU included
1 tenant
Basic features
$0/month

Essentials Plan (Paid):

500 MAU included
Multiple tenants
MFA, RBAC
$35/month (B2C)

Wait. The paid plan includes fewer users than the free plan?

Yes. When you upgrade from free to Essentials, you go from 25,000 included MAUs to 500 included MAUs. Want more? Pay per MAU.

The Real Pricing Table

Here's what Auth0 pricing actually looks like:

Plan	Included MAU	Price	Cost per Additional MAU
Free	25,000	$0	N/A (hard limit)
Essentials	500	$35/mo	~$0.07/MAU
Professional	1,000	$240/mo	~$0.24/MAU
Enterprise	Custom	$30k+/year	"Let's talk"

So if you have 10,000 users and want to upgrade to Essentials, you'd pay:

$35 base + (9,500 × $0.07) = $35 + $665 = $700/month

For a cleaner URL and MFA.

What You Actually Get on Free

The free tier is surprisingly capable:

✅ 25,000 monthly active users
✅ Social login (Google, Apple, GitHub, etc.)
✅ Email/password authentication
✅ Passwordless (magic links)
✅ Universal Login (hosted login page)
✅ Basic user management
✅ 3 team members

What you DON'T get:

❌ Multi-factor authentication (MFA)
❌ Role-based access control (RBAC)
❌ Multiple tenants
❌ Custom domains (like auth.yourapp.com)
❌ More than 5 organizations (B2B)

When to Actually Upgrade

Stay on Free if:

You have < 25,000 MAU
You don't need MFA
You can live with dev-xxx.auth0.com
You're B2C or have < 5 B2B customers

Upgrade to Essentials if:

You NEED MFA (compliance, enterprise customers)
You have < 2,000 MAU (cost is reasonable)
Multiple environments are critical (staging/prod tenants)

Upgrade to Professional if:

You need > 3 SSO connections
You have enterprise customers requiring specific compliance
You're at the "money is less important than time" stage

Go Enterprise if:

You have > 25,000 MAU anyway
You need 99.99% SLA
You want a dedicated account manager to yell at

The Alternative: Don't Upgrade

Here's my actual decision:

Keep the free plan - 25,000 MAU is plenty for now
Accept the ugly URL - Users see it for ~1 second during OAuth redirect
Revisit when we need MFA - That's the real trigger, not vanity URLs

The dev-exjsxdx8c6qt3uhf.us.auth0.com domain is ugly, but it works. Users don't care. They're looking at their phone, waiting for the login to complete.

The Real Question

Before upgrading Auth0, ask yourself:

If it's the latter, save your money. Put it toward features your users actually see.

Why Not Self-Host?

"Just implement auth yourself" is advice I hear often. Here's why I'm staying with Auth0:

Auth0 handles:

Password hashing (bcrypt/argon2)
Password reset flows
Email verification
Brute force protection
Account lockout
Breach detection
Compliance (SOC2, HIPAA options)

One auth mistake = security incident. Auth0's free tier is free insurance.

The value isn't the login page. It's not storing passwords in your database.

What's your auth setup? Self-hosted, Auth0, Clerk, something else? I'm curious what other indie hackers are using.

Building jo4.io - a URL shortener that definitely doesn't store your passwords.

Publishing an Expo App to the App Store: The Parts Nobody Warns You About

Anand Rathnas — Thu, 07 May 2026 01:36:17 +0000

"Just run eas build --platform ios --auto-submit and you're done!"

Famous last words.

The Problem

I had a React Native app built with Expo. Android was already live on the Play Store. iOS should be the same process, right?

Here's what actually happened over the next 4 hours.

Part 1: The Provisioning Profile Dance

First build attempt:

❌ Provisioning profile doesn't support the App Groups capability

My app has a Share Extension (for sharing URLs from other apps). Share Extensions need their own bundle ID, their own provisioning profile, and their own set of capabilities.

The fix:

Go to Apple Developer Portal → Identifiers
Find both your main app ID AND the ShareExtension ID
Enable "App Groups" capability on BOTH
Go to Profiles → Delete the old profiles
Let EAS regenerate them

EAS will ask to create new profiles. Say yes. It knows what it's doing (mostly).

Part 2: Sign in with Apple - The Checkbox That Wasn't

Apple requires apps with third-party login to also offer Sign in with Apple. My app uses Auth0, which supports Apple auth. Should be simple.

Build attempt #2:

❌ Disabled: Sign In with Apple

The app.config.js was missing one line:

ios: {
  // ... other config
  usesAppleSignIn: true  // This one. This is the line.
}

Added it, rebuilt. Profile regenerated with the capability. Build succeeded.

Part 3: The "invalid_client" Mystery

App built. App ran. Tapped "Sign in with Apple."

invalid_client

Checked Auth0 config. Everything looked right:

Client ID: io.jo4.mobile ✓
Team ID: correct ✓
Key ID: correct ✓
Private key: pasted from .p8 file ✓

Spent 30 minutes rechecking these values.

Turns out, the Apple Sign in Key I created had empty "Enabled Services". The key existed but wasn't actually configured for Sign in with Apple.

The fix:

Apple Developer → Keys → Click your key → Edit
Check "Sign in with Apple"
Click Configure → Select your app as Primary App ID
Save

Tried again:

invalid_request
Invalid client id or web redirect url

Different error. Progress.

Part 4: Services ID - The Thing Auth0 Docs Bury

Here's what I didn't understand: Auth0 uses a web-based OAuth flow for Apple Sign in (via Universal Login). This means Apple sees it as a web app, not a native app.

Web apps need a Services ID, not just an App ID.

The fix:

Apple Developer → Identifiers → Create Services ID
Name it something like io.jo4.mobile.auth0
Enable "Sign in with Apple"
Configure with:
- Primary App ID: Your main app
- Domains: your-tenant.us.auth0.com
- Return URLs: https://your-tenant.us.auth0.com/login/callback
Update Auth0's Apple connection to use the Services ID as the Client ID

Finally:

✅ Sign in with Apple works

The Complete Checklist

For anyone doing this in the future:

Apple Developer Portal

[ ] App ID has "Sign in with Apple" capability
[ ] App ID has "App Groups" capability (if using extensions)
[ ] ShareExtension ID has matching capabilities
[ ] Key created with "Sign in with Apple" enabled
[ ] Key configured with correct Primary App ID
[ ] Services ID created (for Auth0/web-based flows)
[ ] Services ID configured with Auth0 domain and callback URL

app.config.js (Expo)

ios: {
  bundleIdentifier: "your.bundle.id",
  usesAppleSignIn: true,
  entitlements: {
    "com.apple.security.application-groups": [
      "group.your.bundle.id"
    ]
  }
}

Auth0

[ ] Apple connection uses Services ID as Client ID (not App ID)
[ ] Team ID, Key ID, and private key are correct

EAS

[ ] Delete old provisioning profiles if capabilities changed
[ ] Let EAS regenerate profiles with new capabilities

Lessons Learned

EAS is magic, until it isn't. The happy path is genuinely one command. The unhappy path is a maze of Apple portals.
Capabilities cascade. If your main app needs a capability, your extensions probably do too.
Auth0 + Apple = Services ID. This isn't obvious from either company's docs. Web-based OAuth flows need a Services ID, not an App ID.
Apple's error messages lie. "invalid_client" can mean the key isn't configured. "invalid_request" can mean you need a Services ID. Neither error tells you this.
The App Store submission is the easy part. Once EAS builds successfully with --auto-submit, it just... works. The hard part is getting that first successful build.

Building a mobile app? Save yourself the debugging session and bookmark this checklist.

Building jo4.io - a URL shortener with a mobile app that now actually exists on the App Store.

Why We Killed Hold Windows in Our Affiliate Marketplace

Anand Rathnas — Sat, 02 May 2026 01:35:40 +0000

We spent weeks building a settlement system for our affiliate marketplace. Hold windows. Clawbacks. Carry-forwards. Commission auto-approval schedulers. The works.

Then we deleted it all.

What We Built (and Why)

The idea was straightforward: when an affiliate drives a conversion, don't pay them immediately. Hold the commission for X days. If the customer refunds, claw back the commission. If there's a remainder below the payout threshold, carry it forward to next month.

Sounds reasonable, right? Every major affiliate network does something like this.

So we built:

Hold windows — configurable per campaign (7, 14, 30 days)
Clawback logic — refunds during hold period reduce the affiliate's balance
Carry-forwards — sub-threshold amounts roll to next settlement period
Auto-approval scheduler — commissions move from HELD → APPROVED after the hold window

What Went Wrong

Legal review flagged it.

The problem wasn't technical — it was regulatory. Holding affiliate funds creates obligations:

Money transmission concerns — holding and releasing funds on a schedule starts to look like money transmission in some jurisdictions
Dispute resolution requirements — clawbacks need a formal dispute process, not just an automatic deduction
Accounting complexity — carry-forwards create accrued liabilities that need proper bookkeeping
Tax reporting — when was the income earned? When the conversion happened, when the hold expired, or when the payout was made?

We're a URL shortener that added an affiliate marketplace. We're not a payment processor. Building the compliance infrastructure for hold windows was going to cost more than the feature was worth.

What We Did Instead

Deleted it. All of it.

- CommissionAutoApprovalScheduler.java (deleted)
- holdWindowDays field (removed from campaigns)
- clawbackAmount, previousCarryForward (removed from settlements)
- HELD commission status (removed)

Replaced with:

Firm offers — brands mark campaigns as non-negotiable. Publishers accept the commission as-is. No back-and-forth.
Immediate settlement — conversions are confirmed by Stripe webhooks. When Stripe says the charge succeeded, the commission is earned. Period.
Monthly payouts — simple monthly settlement with no holds. If there's a refund, the brand eats it (they can adjust their commission rates accordingly).

What We Added

The simplification freed up time for features that actually matter:

Partnership lifecycle — pause, resume, terminate partnerships with full event tracking
Multi-channel notifications — email, in-app, and push notifications for partnership events
Campaign budgets and expiry — brands set a maximum spend and end date, campaigns auto-pause when limits are hit
Firm offers — skip the negotiation dance when the brand knows what they want to pay

The Numbers

Metric	Before	After
Settlement-related DB tables	5	2
Commission statuses	6 (PENDING, HELD, APPROVED, CLAWED_BACK, PAID, FAILED)	3 (PENDING, APPROVED, PAID)
Settlement logic (lines)	~800	~200
Legal questions	Many	Few

Lessons Learned

Legal review before building, not after — we should have asked "can we hold affiliate funds?" before writing a single line of code. Would have saved weeks.
Complexity is a liability — every line of settlement logic was a potential bug, a potential legal issue, and a potential support ticket. Less code = less risk.
Copy the leader carefully — "Amazon Associates does hold windows" doesn't mean you should. Amazon has a legal team. You have a Notion doc.
Simpler products attract more users — publishers don't want to learn about hold windows and carry-forwards. They want to drive traffic and get paid.
KISS isn't lazy, it's strategic — deleting working code feels wrong. It's not. It's the highest-ROI engineering decision you can make.

Ever deleted a feature you spent weeks building? What was the hardest "kill your darlings" moment in your product? Share below.

Building jo4.io — a URL shortener with an affiliate marketplace that pays publishers without the complexity.

3 Auth Bugs We Shipped to Production (Spring + Auth0)

Anand Rathnas — Fri, 01 May 2026 01:37:02 +0000

We found three authentication bugs in production. Not from penetration testing. Not from a security audit. From a single user saying "I can't log in sometimes."

All three bugs were interconnected. Fixing one revealed the next. We shipped the fix in a single commit because pulling on one thread unraveled the whole chain.

Here's each bug, why it existed, and how we fixed it.

Bug 1: The 405 That Shouldn't Exist

Symptom: Sentry alerts showing HttpRequestMethodNotSupportedException — HTTP 405 "Method Not Allowed" — on endpoints that absolutely accept the methods being used.

Investigation: The stack traces pointed at bot traffic. Scanners probing random paths with random HTTP methods. PROPFIND /admin. OPTIONS /api/v1/protected/users. TRACE /oauth/token.

These should return 404 or be handled gracefully. Instead, they were hitting our impersonation filter, which assumed any request reaching it was a valid authenticated request. When the filter tried to process a PROPFIND request on a path that only accepts GET, Spring threw a MethodNotAllowed before our error handler could catch it.

The fix: Add HttpRequestMethodNotSupportedException to our global exception handler:

@ExceptionHandler(HttpRequestMethodNotSupportedException.class)
public ResponseEntity<ErrorResponse> handleMethodNotAllowed(
        HttpRequestMethodNotSupportedException ex) {
    return ResponseEntity.status(HttpStatus.METHOD_NOT_ALLOWED)
            .body(ErrorResponse.of("Method not allowed"));
}

Simple. But finding it required understanding that our filter was letting garbage requests through to the controller layer.

Which led us to Bug 2.

Bug 2: The Filter That Ran Too Early

Symptom: Admin impersonation — a feature that lets support staff act as a specific user — worked sometimes. Other times it silently failed and the admin saw their own account instead of the target user.

The architecture: We have an ImpersonationFilter that checks for an X-Impersonate-User header. If present and the caller is an admin, it swaps the security context to the target user.

The problem: The filter executed before our user sync filter.

In our Auth0 integration, the first request from a new Auth0 user triggers a "sync" — we look up the Auth0 subject in our database and create a local user record if one doesn't exist. This happens in Auth0UserSyncFilter.

The filter chain looked like this:

Request → ImpersonationFilter → Auth0UserSyncFilter → Controller

When an admin's first request included the impersonation header:

ImpersonationFilter runs. Tries to look up the admin user. But the admin hasn't been synced yet. Lookup returns null. Impersonation silently fails.
Auth0UserSyncFilter runs. Creates the admin user record.
Controller runs. Admin sees their own account, not the target.

On the second request, the admin user exists. Impersonation works. Hence "works sometimes."

The fix: Reorder the filters:

Request → Auth0UserSyncFilter → ImpersonationFilter → Controller

The sync must happen before any filter that depends on the user existing in the database. We enforced this with explicit @Order annotations:

@Order(1)  // Runs first — ensures user exists
public class Auth0UserSyncFilter extends OncePerRequestFilter { ... }

@Order(2)  // Runs second — can now look up the user
public class ImpersonationFilter extends OncePerRequestFilter { ... }

Spring Security's filter chain doesn't guarantee ordering by default. If you register filters without explicit ordering, you're at the mercy of component scanning order, which can vary between environments.

Bug 3: The Race Condition in User Creation

Symptom: Intermittent DataIntegrityViolationException — duplicate key constraint on the users table — during peak traffic.

Root cause: The Auth0 user sync had a classic check-then-act race condition:

// Thread A                         // Thread B
user = findByAuth0Sub(sub);         user = findByAuth0Sub(sub);
// user is null                     // user is null
user = createUser(sub, email);      user = createUser(sub, email);
// SUCCESS                          // DataIntegrityViolationException!

Two concurrent requests from the same user (common on app startup — the mobile app fires multiple API calls simultaneously) both see "user doesn't exist" and both try to create the record. One succeeds. One hits the unique constraint.

The fix: Catch the constraint violation and retry the lookup:

UserEntity syncUser(String auth0Sub, String email) {
    UserEntity existing = userRepository.findByAuth0Sub(auth0Sub);
    if (existing != null) {
        return existing;
    }

    try {
        return createNewUser(auth0Sub, email);
    } catch (DataIntegrityViolationException e) {
        // Another thread created the user between our check and insert.
        // Just fetch the record they created.
        UserEntity raced = userRepository.findByAuth0Sub(auth0Sub);
        if (raced != null) {
            return raced;
        }
        throw e;  // Genuine constraint violation, not a race
    }
}

This is the optimistic concurrency pattern. Instead of acquiring a lock before the check (pessimistic), we let the race happen and recover from the loser's exception. It's cheaper under normal load (no locking overhead) and handles the edge case gracefully.

Why All Three Were Connected

The 405 errors drew attention to our filter chain. Investigating the filter chain revealed the ordering bug. Fixing the ordering bug and putting more load on the sync path exposed the race condition.

It's a common pattern in production debugging: the bug you're investigating isn't the bug that matters. It's the thread that leads you to the real problem.

Lessons Learned

Handle every HTTP method in your exception handler. Bots send PROPFIND, TRACE, PATCH to paths that don't support them. Don't let these bubble up as unhandled exceptions.
Spring filter ordering is not implicit. If Filter B depends on state created by Filter A, use @Order to guarantee A runs first. Don't rely on component scan order — it varies.
Check-then-act is a race condition. If two threads can execute the "check" simultaneously, they'll both proceed to "act." Use optimistic concurrency (catch + retry) or pessimistic locking (SELECT FOR UPDATE).
Mobile apps create concurrent requests on startup. When the app opens, it often fires 3-5 API calls in parallel (user profile, notifications, config). If your user sync runs per-request, you will hit the race condition.
One bug leads to another. Don't stop when you fix the surface issue. Ask: "Why did this request reach this code path in the first place?"

What's the most interconnected set of bugs you've found in production? Share the debugging chain in the comments.

Building jo4.io — a multi-tenant platform where auth bugs are never "just" auth bugs.

The One-Character OAuth Bug That Broke Our API

Anand Rathnas — Fri, 01 May 2026 01:36:58 +0000

Our OAuth implementation worked perfectly. Every test passed. Users authorized apps, got tokens, refreshed them. Textbook OAuth 2.0.

Then a Pipedream integration broke.

The Problem

A user reported that their Pipedream workflow couldn't access certain API endpoints. The token was valid, the scopes were granted — but the API returned 403 Forbidden.

The error logs showed the token had zero scopes. That's impossible — we confirmed the user authorized read:urls write:urls during the consent flow.

The Root Cause

OAuth 2.0 (RFC 6749) defines scopes as space-delimited:

scope = "read:urls write:urls"

But some OAuth clients send them comma-delimited:

scope = "read:urls,write:urls"

Our scope parser split on spaces. Pipedream sent commas. The parser saw "read:urls,write:urls" as a single unknown scope, which mapped to zero valid scopes.

One character. Comma vs space.

// Before: only splits on space
String[] scopes = scopeString.split(" ");

// After: splits on comma OR space
String[] scopes = scopeString.split("[,\\s]+");

That's the fix. One regex character class. The rest of this post is about making sure it never happens again.

The Test Suite

We wrote a full end-to-end OAuth integration test: 1,605 lines covering the complete flow.

The test covers:

Authorization code request — with various scope formats
Token exchange — authorization code → access token
Token refresh — refresh token → new access token
Scope validation — comma-delimited, space-delimited, mixed, duplicates
Error cases — invalid codes, expired tokens, revoked grants
Real API calls — using the token against actual protected endpoints

The scope parsing tests specifically:

// Space-delimited (RFC 6749 standard)
assertScopeParsed("read:urls write:urls", Set.of("read:urls", "write:urls"));

// Comma-delimited (common in practice)
assertScopeParsed("read:urls,write:urls", Set.of("read:urls", "write:urls"));

// Mixed (yes, this happens)
assertScopeParsed("read:urls, write:urls", Set.of("read:urls", "write:urls"));

// Duplicates
assertScopeParsed("read:urls read:urls", Set.of("read:urls"));

Lessons Learned

RFCs are prescriptive, clients are creative — the spec says space-delimited, but real clients do whatever they want. Parse generously.
E2E tests catch what unit tests miss — our unit tests for scope parsing passed because they all used space-delimited scopes. The integration path through the actual OAuth flow with a real client exposed the mismatch.
One-character bugs hide in plain sight — the scope string looked correct in logs. You had to know that read:urls,write:urls was one scope, not two, to spot the problem.
Test the integration, not the unit — for auth flows especially, the value is in testing the full chain: consent → code → token → API call. Mocking any part of that chain hides bugs like this one.

Ever been bitten by a delimiter bug? What's the smallest change that broke your production? Drop it in the comments.

Building jo4.io — a URL shortener with a developer API that actually works.

The Idempotency Bug That Spammed dev.to's API for Weeks

Anand Rathnas — Sat, 25 Apr 2026 01:34:40 +0000

We built a small tool to keep our dev.to posts in sync with our markdown source files. Write locally, push to Git, and the tool updates dev.to if anything changed. Simple.

One morning, we noticed dev.to showing "Updated 2 hours ago" on an article we hadn't touched in weeks.

Then we checked the logs. Every article with an updatedAt field in its frontmatter was being republished. Every. Single. Day.

How the Sync Works

The tool is straightforward:

Read markdown posts with frontmatter (title, publishAfter, updatedAt, etc.)
For each post already on dev.to, check: "Has the local version changed since last sync?"
If isUpdateNeeded() returns true, PUT the latest content to dev.to's API

The check logic:

function isUpdateNeeded(localPost, devtoArticle) {
  // If local content changed after dev.to publish date, update needed
  const localDate = localPost.updatedAt || localPost.publishAfter;
  const devtoDate = devtoArticle.published_at;
  return new Date(localDate) > new Date(devtoDate);
}

Looks reasonable. If the local post was updated after it was published on dev.to, push the update.

The Bug

Here's a timeline of what actually happens:

Day 1: Post published with publishAfter: "2026-03-01", no updatedAt
Day 1 sync: Script creates article on dev.to. published_at = 2026-03-01T01:00:00Z
Day 5: We fix a typo. Set updatedAt: "2026-03-05" in frontmatter
Day 5 sync: isUpdateNeeded() → 2026-03-05 > 2026-03-01 → true. Updates dev.to. Correct.
Day 6 sync: isUpdateNeeded() → 2026-03-05 > 2026-03-01 → true. Updates dev.to again. Wrong.
Day 7 sync: Same thing. And Day 8. And Day 9. Forever.

The problem: updatedAt in the frontmatter is a static value. It doesn't change after Day 5. But published_at on dev.to reflects the original publish date, not the last update. So updatedAt > published_at is permanently true.

Every sync run thinks the article needs updating because the local update date is after the original publish date. It will never become false.

Why This Is an Idempotency Failure

An idempotent operation produces the same result whether you run it once or a hundred times. Our sync was not idempotent because:

The comparison updatedAt > published_at doesn't account for "has this update already been pushed?"
There's no record of "we already synced this version"
The trigger condition never resets

This is the classic state management trap in automation: comparing a static input timestamp against a fixed reference point creates a permanently true condition.

The Fix

We needed the sync to know: "Have I already pushed this update?" The answer was to compare against dev.to's edited_at field (which reflects the last API update), not published_at:

function isUpdateNeeded(localPost, devtoArticle) {
  const localDate = localPost.updatedAt || localPost.publishAfter;
  // Compare against last edit, not original publish
  const devtoDate = devtoArticle.edited_at || devtoArticle.published_at;
  return new Date(localDate) > new Date(devtoDate);
}

Now the timeline works:

Day 5 sync: 2026-03-05 > 2026-03-01 → true. Updates dev.to. edited_at = 2026-03-05T01:00:00Z
Day 6 sync: 2026-03-05 > 2026-03-05 → false. No update. Done.

The second piece was handling the null propagation. When there's no update and we sync metadata, the script was using Object.assign() to merge frontmatter. But Object.assign skips undefined values — so when updatedAt wasn't set, the old value persisted instead of being cleared:

// Before: Object.assign ignores undefined, so stale updatedAt persists
const merged = Object.assign({}, defaults, frontmatter);

// After: explicitly handle null/undefined fields
const merged = { ...defaults, ...frontmatter };
if (!frontmatter.updatedAt) {
  delete merged.updatedAt;  // Don't carry forward stale dates
}

The Broader Lesson

Every automation system that syncs state between two systems needs to answer this question: "How do I know this sync already happened?"

Common patterns:

Approach	Pros	Cons
Compare timestamps (what we did, fixed)	Simple, no extra storage	Must compare correct timestamps
Store sync hash	Deterministic, content-based	Extra storage/state to manage
Idempotency key per sync	Guarantees exactly-once	Complex, needs key generation
Event sourcing	Full audit trail	Heavy for simple use cases

For content crossposting, timestamp comparison is the right level of complexity. You just need to compare against the right timestamp — the one that reflects "when was this last synced?" not "when was this first published?"

How We Caught It

Honestly? By accident. We noticed articles on dev.to showing "Updated recently" when we knew we hadn't changed them. A quick look at the sync logs confirmed it — the same articles being pushed on every run. The fix was five lines of logic. The debugging was thirty minutes of reading logs.

The embarrassment of silently spamming dev.to's API for weeks? Immeasurable.

Takeaways

Idempotency isn't optional in automation. If your sync can run twice and produce different results (or the same unnecessary result), it's broken.
Test your sync with unchanged content. Run your pipeline twice in a row. Does the second run do nothing? If not, you have a bug.
published_at and edited_at are different things. Most APIs have both. Use the right one for your comparison.
Object.assign doesn't propagate undefined. If you're merging objects where "missing" is meaningful state, handle it explicitly.
Monitor your automation output, not just success/failure. Our script returned 200 every time. It was "succeeding" at doing unnecessary work.

Have you been bitten by an idempotency bug in your automation? What was the trigger? Drop it below.

Building jo4.io — a URL shortener with analytics, bio pages, and an affiliate marketplace for creators.

Why Safari Said 'Link Not Found' (And Chrome Didn't)

Anand Rathnas — Wed, 22 Apr 2026 01:35:15 +0000

If you build a URL shortener and your links show "Link Not Found" on Safari, you have approximately zero seconds before your support inbox catches fire.

That's what happened to us. Chrome, Firefox, Edge — all fine. Safari on iOS and macOS — intermittent "This link could not be found or has expired." For a product whose entire job is redirecting links, this was existential.

The Symptom

Users would tap a short link on their iPhone. Instead of landing on the destination, they'd see our error page flash briefly — "Link Not Found" — then the correct page would load a moment later.

Some users saw it every time. Some never saw it. The flash was fast enough that screenshots were hard to capture. We couldn't reproduce it consistently on desktop Safari.

The only consistent signal: it never happened on Chrome.

Laying Breadcrumbs

We couldn't reproduce it reliably, so we shipped debug instrumentation. A useRef array that logged every function call with timestamps, persisted to localStorage so it survived the page navigation that was about to happen.

The debug output from a user's device told the story:

[0] { event: "handleRedirect called", timestamp: 1709683200001 }
[1] { event: "API success, redirecting", timestamp: 1709683200250 }
[2] { event: "handleRedirect called", timestamp: 1709683200252 }
[3] { event: "API error: request cancelled", timestamp: 1709683200260 }

Entry [2] was the smoking gun. handleRedirect was being called twice. The second call happened 2 milliseconds after the first one successfully redirected.

The Root Cause

Here's what our RedirectPage component did:

Mount → call handleRedirect() via useEffect
handleRedirect() resolves the URL via API
On success, call safeRedirect(targetUrl) (sets window.location.href)
After redirect, update state: markVisitedInSession() sets hasVisitedInSession from false → true
handleRedirect was wrapped in useCallback with hasVisitedInSession as a dependency

Step 5 is where it breaks. When the state changes, React creates a new handleRedirect callback identity. The useEffect sees a new dependency and re-fires the callback.

But wait — we already navigated away. Why does the second call matter?

Because Safari doesn't stop.

Chrome: When you set window.location.href, Chrome immediately halts JavaScript execution on the current page. The navigation takes over. The second handleRedirect call never happens.

Safari: When you set window.location.href, Safari continues executing JavaScript while the navigation is in progress. The second handleRedirect fires, starts an API request, but the page is mid-navigation. The HTTP request gets cancelled. The catch block runs. The error page renders.

The user sees: flash of "Link Not Found" → destination page loads.

The Fix

Five lines:

const hasRedirected = useRef(false);

const handleRedirect = useCallback(async (pwd?: string) => {
  if (hasRedirected.current && !pwd) return;  // Guard

  // ... resolve URL, check previews, etc ...

  hasRedirected.current = true;  // Set before triggering navigation
  safeRedirect(targetUrl, '/');
}, [/* deps */]);

A useRef — not useState — because we specifically don't want to trigger a re-render. The ref persists across renders, survives the callback identity change, and silently blocks the second call.

The && !pwd clause allows retries for password-protected URLs where the user submits a password.

Why useRef Instead of useState

This is the subtle part. If we'd used useState for the guard:

const [hasRedirected, setHasRedirected] = useState(false);

Setting it to true would trigger another re-render, which could create another callback identity change, which could re-fire the effect again. We'd be fighting React's render cycle with React's render cycle.

useRef sidesteps the entire problem. It mutates silently. No render. No new callback. No re-fire.

What We Removed

After confirming the fix worked across Safari, Chrome, and Firefox, we stripped out the debug instrumentation — the localStorage logging, the debug panel on the error page. It served its purpose.

But we kept the useRef guard. It's three lines of defense against a browser behavior difference that no amount of testing would have caught in CI.

Lessons Learned

Browsers diverge on navigation behavior. Chrome halts JS on window.location.href. Safari doesn't. This isn't a bug in either browser — the spec doesn't mandate when to stop execution.
useCallback + useEffect dependencies can create invisible re-execution loops. If your callback updates state that's in its own dependency array, you have a loop. It's just usually invisible because the page navigated away before it matters.
Ship debug instrumentation to production. When you can't reproduce a bug locally, instrument the code path, ship it behind a flag or with minimal overhead, and let the user's device tell you what happened.
useRef is your escape hatch from React's reactivity. When you need to track state that should NOT trigger renders, refs are the right tool.

Ever been bitten by a Safari-specific JS behavior? What was it? Drop it in the comments.

Building jo4.io — a URL shortener that works on every browser. Yes, even Safari.

Referral Tracking for Indie Hackers: Skip the $300/mo Tools

Anand Rathnas — Thu, 19 Mar 2026 01:35:44 +0000

I needed referral tracking for my SaaS. The options were depressing.

When I checked (early 2026): ReferralCandy started at $59/mo, designed for e-commerce. Rewardful at $29/mo, but that's just the starting tier. FirstPromoter and PartnerStack were priced for larger teams.

I'm a solo founder. My MRR is in the hundreds, not thousands. Every dollar saved is another month of runway.

Here's the thing: I don't need a referral platform. I need to know which users came from which invite link. That's it.

What I Actually Needed

Let me break down the "enterprise referral solution" into what matters:

Unique links per referrer - So I know who sent them
Click tracking - How many people clicked
Attribution - Connect the click to a signup

The first two are literally what URL shorteners do. The third is a query parameter and some code.

The Setup

I created invite links using jo4.io:

https://jo4.io/invite-sarah → myapp.com/signup?ref=sarah
https://jo4.io/invite-mike  → myapp.com/signup?ref=mike
https://jo4.io/invite-alex  → myapp.com/signup?ref=alex

Each referrer gets a memorable short link. Jo4 tracks clicks automatically. My signup form reads the ref parameter and stores it.

Total cost: $0 (free tier covers this easily).

The Analytics I Get

For each invite link, jo4 shows me:

Total clicks - How many people hit the link
Unique visitors - Deduplicated by IP
Geographic breakdown - Where clicks came from
Device/browser - Mobile vs desktop
Referrer - Where the link was shared (Twitter, email, etc.)
Timeline - When clicks happened

This is more data than I had with the $59/mo tool I tried last year.

Handling Attribution

On my signup page:

// Grab the ref parameter
const params = new URLSearchParams(window.location.search);
const referrer = params.get('ref');

if (referrer) {
  // Store it for the signup request
  localStorage.setItem('referrer', referrer);
}

On signup submission:

const referrer = localStorage.getItem('referrer');

await fetch('/api/signup', {
  method: 'POST',
  body: JSON.stringify({
    email,
    password,
    referredBy: referrer || null
  })
});

That's it. Now I have a referred_by column in my users table.

What About Rewards?

"But what about paying out referral bonuses?"

I run a report once a month:

SELECT referred_by, COUNT(*) as signups
FROM users
WHERE referred_by IS NOT NULL
AND created_at > NOW() - INTERVAL '30 days'
GROUP BY referred_by
ORDER BY signups DESC;

Then I send PayPal/Wise payments manually. At my scale (< 50 referrals/month), this takes 10 minutes.

When I'm at 500 referrals/month, I'll automate it. Or I'll pay for a tool. But I'll also have the revenue to justify it.

Advanced: UTM Tracking

For power referrers who share on multiple platforms, I give them UTM-tagged variants:

https://jo4.io/sarah-twitter → myapp.com/signup?ref=sarah&utm_source=twitter
https://jo4.io/sarah-youtube → myapp.com/signup?ref=sarah&utm_source=youtube
https://jo4.io/sarah-newsletter → myapp.com/signup?ref=sarah&utm_source=newsletter

Now I know not just WHO referred them, but WHERE. Jo4's analytics show me which links perform best.

The Numbers

After 3 months with this setup:

47 referral signups tracked
$0 spent on referral tools
$2,820 saved vs. the "affordable" option
10 minutes/month on manual payouts

The enterprise tools have dashboards and automation. I have a SQL query and a spreadsheet. At my scale, that's the right tradeoff.

When to Upgrade

I'll pay for a real referral platform when:

Referral volume exceeds 100/month (manual payouts become painful)
I need tiered rewards (different rates for different referrers)
Compliance requires audit trails I can't build myself

Until then, a URL shortener with analytics does 80% of the job at 0% of the cost.

Running a referral program on a budget? Share your setup in the comments.

Building jo4.io - URL shortener with analytics that indie hackers actually use for invite links, affiliate tracking, and campaign attribution.

20 Free Developer Tools We Built (And Why We Gave Them Away)

Anand Rathnas — Tue, 17 Mar 2026 01:35:06 +0000

You know those random utility websites you visit once, use for 30 seconds, and never think about again?

We built 20 of them. And put them all in one place at jo4.io/u.

No signup. No ads. No "subscribe to access." Just tools.

Why Build Free Tools on a Paid Product?

We're a URL shortener. People pay us for short links, analytics, and QR codes. So why give away free tools?

1. We Needed Them

This is the honest answer. While building jo4, we constantly needed:

JWT decoder to debug OAuth tokens
Base64 encoder/decoder for API payloads
JSON formatter to read webhook responses
Timestamp converter to debug expiration issues
Hash generator for testing HMAC signatures

We were opening random websites, getting hit with ads and popups, and thinking "this is stupid." So we built our own.

2. We're Developer-Friendly

Our tagline is literally "Built for developers who ship." If we're going to claim that, we need to prove it.

Free tools with no signup, no dark patterns, no BS—that's what developer-friendly looks like. It's not just marketing. It's our identity.

3. SEO (Yes, Also This)

Every developer searching for "base64 decoder" or "jwt decoder online" is a potential customer who might also need a URL shortener. The tools get traffic, the traffic discovers our main product.

It's a legitimate marketing play. But the difference is: we built tools we actually use. Not half-baked "sign up to see results" garbage.

The Full List

Encoding & Decoding

Tool	URL	What It Does
Base64 Encoder/Decoder	/u/b64	Encode/decode Base64 strings
URL Encoder/Decoder	/u/encode	Encode/decode URL components
JWT Decoder	/u/jwt	Decode and inspect JSON Web Tokens

JWT Decoder is our most-used tool. Paste a token, instantly see the header, payload, and expiration time. No external requests—everything happens in your browser.

Generators

Tool	URL	What It Does
Password Generator	/u/pwd	Generate secure passwords with strength meter
UUID Generator	/u/uuid	Generate v1, v4, and v7 UUIDs
Random Generator	/u/random	Generate random strings, numbers, UUIDs
Hash Generator	/u/hash	Generate MD5, SHA-1, SHA-256, SHA-512 hashes
Lorem Ipsum Generator	/u/lorem	Generate placeholder text
QR Code Generator	/u/qr	Create QR codes with custom colors and sizes

Password Generator calculates actual entropy, not fake "strength bars." A 12-character password with all character types = ~79 bits of entropy. We show the math.

Text Tools

Tool	URL	What It Does
JSON Formatter	/u/json	Format, validate, beautify JSON
Markdown Preview	/u/md	Write and preview markdown in real-time
Diff Checker	/u/diff	Compare two texts, supports JSON/YAML
Text Case Converter	/u/case	Convert between UPPER, lower, camelCase, snake_case
Word Counter	/u/words	Count words, characters, sentences, reading time
URL Slug Generator	/u/slug	Convert text to clean, SEO-friendly slugs

Diff Checker is surprisingly powerful. It auto-detects JSON/YAML and formats before comparing, so you can paste minified JSON and still get a readable diff.

Converters

Tool	URL	What It Does
Color Converter	/u/color	Convert between HEX, RGB, HSL, HSV
Unix Timestamp Converter	/u/time	Convert timestamps to human dates and back

Unix Timestamp Converter handles milliseconds vs seconds automatically. No more "is this 10 digits or 13?" confusion.

URL & Marketing Tools

Tool	URL	What It Does
UTM Builder	/u/utm	Build URLs with UTM parameters for campaign tracking
URL Checker	/u/check	Check DNS, SSL, redirects, and safety status
OG Preview	/u/og	Preview how URLs appear on social media

UTM Builder ties directly into our URL shortener. Build your UTM link, optionally shorten it, track everything. Full funnel in one page.

Design Philosophy

1. Client-Side First

Most tools run entirely in your browser. No server requests. No data sent anywhere. When you paste a JWT, it never leaves your machine.

The only tools that require API calls:

URL Checker (needs to fetch the actual URL)
OG Preview (needs to fetch metadata)

And even those are rate-limited and don't store anything.

2. No Dark Patterns

No "sign up to see results"
No "share to unlock"
No interstitial ads
No newsletter popups
No fake urgency

You land on the page, use the tool, leave. That's it.

3. Keyboard-First

Every tool supports:

Ctrl/Cmd + Enter to execute
Ctrl/Cmd + C to copy result
Esc to clear

We use these tools daily. Keyboard shortcuts matter.

4. Mobile-Responsive

All tools work on mobile. The text areas resize. The buttons are tap-friendly. You can decode a JWT on your phone at 2 AM when production is on fire.

Not that we've ever done that.

The Tech Stack

React + TypeScript + Tailwind CSS
├── Client-side crypto for hashes
├── Client-side JWT parsing
├── Client-side QR generation
├── RTK Query for API calls
└── Shared UI components (shadcn/ui)

Each tool is a standalone page component. No shared state. No complex routing. Load fast, do one thing well.

Usage Stats (The SEO Payoff)

After 3 months:

Tool	Monthly Visits
JWT Decoder	~4,200
JSON Formatter	~3,100
Base64 Encoder	~2,400
Password Generator	~1,800
Others combined	~3,500

Total: ~15,000 monthly visitors who now know jo4.io exists.

Conversion to paid? Low, around 0.3%. But that's 45 paying customers who found us through free tools. At $16/month average, that's $720 MRR from SEO content that costs us nothing to maintain.

Tools We're Still Building

The /u/* pattern works. We're adding more:

Cron Expression Builder - Build and explain cron expressions
Regex Tester - Test regex patterns with live matching
HTTP Header Inspector - See request/response headers for any URL
SVG to PNG Converter - Convert SVG files to raster images

If you have suggestions, let us know.

The Full Directory

Everything lives at jo4.io/u. Bookmark it. Use it. Tell your friends.

Category	Tools
Encoding	Base64, URL Encode, JWT Decode
Generators	Password, UUID, Random, Hash, Lorem, QR
Text	JSON, Markdown, Diff, Case, Word Count, Slug
Converters	Color, Timestamp
Marketing	UTM Builder, URL Checker, OG Preview

20 tools. Zero signup. Zero cost.

What tools do you wish existed? We're always looking for ideas.

Building jo4.io - URL shortener with analytics, plus 20 free developer tools at jo4.io/u.

The Easiest Integration We've Ever Done: Two Markdown Files and a Domain Name Identity Crisis

Anand Rathnas — Sat, 14 Mar 2026 01:34:35 +0000

After wrestling with Zapier OAuth and navigating Pipedream's human-first process, we braced ourselves for ClawHub.

"What hoops will we have to jump through this time?"

The answer: None. Zero hoops. Two markdown files. Done.

The Domain Name Identity Crisis

Before we get into the integration, let's address the elephant in the room.

This platform has had more domain names than I've had hot dinners:

calwd.com → openclaw.ai → clawhub.ai

I'm genuinely not sure what to call it in conversation anymore.

At this point, I half expect to wake up tomorrow and find it's now crabpeople.io.

But here's the thing: the product is actually really good. The domain name musical chairs? Just a startup finding its footing. It happens.

The Integration: Two Files

I'm not exaggerating. The entire Jo4 integration is:

smoothtalk/clawhub/
├── README.md     (33 lines)
└── SKILL.md      (190 lines)

That's it. No OAuth dance. No webhook infrastructure. No SDK to build. Just... markdown.

The README.md

A quick intro for humans:

# Jo4 - URL Shortener & Analytics

🔗 **[jo4.io](https://jo4.io)** - Modern URL shortening with QR codes and detailed analytics.

## Features

- **Short URLs** - Custom aliases, branded links
- **QR Codes** - Auto-generated for every link
- **Analytics** - Clicks, geography, devices, referrers
...

The SKILL.md

This is where the magic happens. It's a markdown file with YAML frontmatter that tells the AI how to use your API:

---
name: jo4
description: URL shortener, QR code generator, and link analytics API
homepage: https://jo4.io
user-invocable: true
metadata:
  openclaw:
    emoji: "🔗"
    primaryEnv: "JO4_API_KEY"
    requires:
      env: ["JO4_API_KEY"]
---

Then you just... document your API. In markdown. With curl examples.

### Create Short URL (Authenticated)

\`\`\`bash
curl -X POST "https://jo4-api.jo4.io/api/v1/protected/url" \
  -H "X-Jo4-API-Key: $JO4_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"longUrl": "https://example.com", "title": "My Link"}'
\`\`\`

The AI reads this, understands the API structure, and can now use it. No code generation. No SDK maintenance. Just documentation that doubles as integration.

Why This Works

ClawHub's approach is beautifully simple:

Documentation IS the integration - If you can document it, it's integrated
Curl examples are universal - Any AI can understand curl -X POST
Environment variables for auth - JO4_API_KEY in the metadata, done
No deployment - Push to their repo, it's live

Compare this to:

Zapier: OAuth implementation, webhook infrastructure, app review, QA queue
Pipedream: GitHub issue, email credentials, component code, QA queue
ClawHub: Write markdown. Push. Done.

The Live Integration

It's already live at clawhub.ai/anandrathnas/jo4.

Users can now ask their AI:

And it just... works. The AI reads the SKILL.md, finds the right endpoint, makes the call.

What We Documented

Section	Purpose
Authentication	How to get and use API keys
Create Short URL	Main endpoint with all parameters
Anonymous URLs	Public endpoint (no auth)
Get URL Details	Retrieve by slug
Get Analytics	Click stats, geo, devices
List URLs	Pagination support
Update/Delete	CRUD operations
QR Codes	Auto-generated URLs
Rate Limits	Plan-based limits
Error Codes	400, 401, 403, 404, 429

All in markdown. All with curl examples. Total effort: maybe 30 minutes.

The Metadata That Makes It Work

The frontmatter is the secret sauce:

metadata:
  openclaw:
    emoji: "🔗"
    primaryEnv: "JO4_API_KEY"
    requires:
      env: ["JO4_API_KEY"]

This tells ClawHub:

Show the 🔗 emoji in the UI
The main credential is JO4_API_KEY
Don't let users invoke without that env var set

No complex OAuth scopes. No token refresh logic. Just "need this env var? yes/no."

Lessons Learned

1. Sometimes Simpler Is Better

After OAuth flows and webhook subscriptions, a markdown file feels almost too easy. But it works. Users get value. That's what matters.

2. Documentation-as-Integration Is Genius

If your docs are good enough for an AI to understand, they're probably good enough for humans too. This forces you to write clear, example-driven documentation.

3. Domain Names Are Just Names

Calwd. OpenClaw. ClawHub. Who cares? The product works. The integration was painless. I'll update my bookmarks as needed.

Integration Complexity Comparison

Platform	Time	Files/Code	Auth	Process
Zapier	1 week	OAuth server + REST Hooks	OAuth 2.0 + PKCE	Review queue
Pipedream	4 days	OAuth + Components	OAuth 2.0 + PKCE	Email + QA
ClawHub	30 min	2 markdown files	API Key env var	Push and done

The Future-Proofing Question

"What if they change the domain again?"

Honestly? I'll update the bookmark. The integration itself won't break—it's just markdown files in a repo.

"What if they rename the whole product?"

Then I'll have another blog post to write. Content calendar wins either way.

Try It Yourself

If you have a REST API with decent documentation, you can probably integrate with ClawHub in an afternoon:

Create a SKILL.md with frontmatter
Document your endpoints with curl examples
Specify required env vars in metadata
Push to their repo
Done

No OAuth implementation. No webhook infrastructure. No SDK maintenance.

Sometimes the best integrations are the ones that don't feel like integrations at all.

What's the easiest integration you've ever done? And have you noticed any other products with domain name identity issues?

Building jo4.io - URL shortener with analytics. Now available on ClawHub... whatever they call it next week.

Getting Your App on Pipedream: No Dashboard, Just Humans (And That's Actually Great)

Anand Rathnas — Wed, 11 Mar 2026 01:34:43 +0000

After getting our Zapier OAuth integration working, we figured Pipedream would be similar. Build the OAuth endpoints, submit the app, wait for approval.

We were half right.

The Plot Twist: No Developer Dashboard

Zapier has a developer platform where you:

Create an app
Configure OAuth settings
Upload your client ID/secret
Submit for review

Pipedream? None of that.

There's no developer dashboard. No self-service portal. No "Create New App" button.

Instead, you open a GitHub issue.

"Wait, what?"

The Process (It's Actually Fast)

Step 1: Open a GitHub Issue

I created issue #19728 with:

App name and description
Link to API documentation
OAuth endpoints
Triggers and actions I wanted to build
Note that I had component code ready

**OAuth 2.0 Details:**
- Authorization URL: https://jo4-api.jo4.io/oauth/authorize
- Token URL: https://jo4-api.jo4.io/oauth/token
- PKCE Support: Yes (required, S256)
- Scopes: read, write

I have the complete component code ready and can submit PR
once OAuth App ID is provided.

Step 2: Human Responds (Same Day!)

Within hours, someone from the Pipedream integrations team replied asking how they could get OAuth 2.0 credentials to start integrating.

No ticket queue. No "we'll get back to you in 3-5 business days." A real person, asking a real question.

Step 3: Exchange Credentials via Email

Here's where it gets interesting. They asked me to email the OAuth client credentials directly to a team member.

No secure portal. No encrypted upload form. Just... email.

Is this concerning? Maybe. But here's the thing: these credentials are specific to Pipedream's redirect URI. They can't be used anywhere else. And the speed of a direct email beats waiting for a ticket system.

Tip I shared with them:

They're probably working on it. But honestly? The current process worked fine.

Step 4: App Submitted for QA

Four days after opening the issue, they confirmed the Jo4 app was submitted for QA as an OAuth 2.0 app.

That's it. From GitHub issue to QA queue in under a week.

The Wait (Current Status)

As of writing, the app is "awaiting QA." When I tried to access the app link, I got a 404:

I asked if the 404 was expected. It was — the app isn't released until it clears QA.

Fair enough. The QA process takes time. But the human interaction throughout has been stellar.

What We Reused from Zapier

The beautiful part: we didn't write new OAuth code.

Our Zapier integration required:

OAuth 2.0 Authorization Code flow
Mandatory PKCE (S256)
Token refresh support
Proper error responses

Pipedream needs... exactly the same thing.

Same endpoints:
  /oauth/authorize
  /oauth/token
  /oauth/userinfo

Same PKCE requirement:
  code_challenge_method: S256

Same token format:
  { access_token, refresh_token, expires_in, scope }

The only difference was creating a new OAuth client with Pipedream's redirect URI:

https://api.pipedream.com/connect/oauth/oa_XXXXX/callback

Everything else? Already done.

The Triggers and Actions

What we're shipping:

Type	Name	Description
Trigger	New URL Created	Webhook fires when user creates a short URL
Trigger	New Referrer Domain	Webhook fires when link gets traffic from new source
Action	Create Short URL	Create with optional custom slug
Action	Get URL Details	Retrieve URL by slug
Action	List URLs	Paginated list of all URLs

Same as Zapier. Same webhook infrastructure. Same REST Hook pattern (subscribe/unsubscribe).

Why Human-First Integration Is Actually Better

I've submitted apps to various platforms. Here's the typical experience:

Fill out 47 form fields
Upload screenshots in specific dimensions
Wait 2 weeks for automated rejection
Resubmit with minor changes
Wait another 2 weeks
Repeat

Pipedream's approach:

Open issue with relevant details
Human asks clarifying questions
Email credentials
App in QA within a week

The human touch catches edge cases faster. Their team noticed I mentioned API keys require an upgrade on our free tier and asked specifically about OAuth credentials. A form wouldn't have caught that nuance.

Timeline Summary

Date	Event
Jan 19	Opened GitHub issue
Jan 19	Pipedream team responds (same day)
Jan 21	Credentials exchanged via email
Jan 23	App submitted for QA
Jan 30	Follow-up—still awaiting QA
Now	Waiting for release

Total time from "I want to integrate with Pipedream" to "app in QA": 4 days.

Lessons Learned

1. OAuth Investment Pays Dividends

The three days we spent getting OAuth right for Zapier? Zero additional work for Pipedream. Same endpoints, same PKCE, same token format.

2. Human Support > Automated Portals (Sometimes)

For small-to-medium apps, direct human contact is faster. Their team answered questions I didn't know I had.

3. Document Everything in the Issue

The more context you provide upfront, the fewer back-and-forth messages. I included:

Full OAuth spec
Available scopes
Trigger/action descriptions
Link to Swagger docs

4. Be Patient with QA

The integration team is fast. QA takes time. That's okay—they're protecting their users.

What's Next

Once the app clears QA, we'll:

Submit the PR with component code
Test the full flow end-to-end
Write documentation
Announce the integration

We'll update this post when it's live.

Have you integrated with Pipedream? What was your experience with their process?

Building jo4.io - URL shortener with analytics. Soon available on Pipedream alongside Zapier.