DEV Community: Anand Rathnas

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.

The 5 Edge Cases That Broke Our Dev.to Auto-Crossposting (And How We Fixed Them)

Anand Rathnas — Sun, 08 Mar 2026 01:34:38 +0000

In our previous post, we covered the producer-consumer problem for blog scheduling. But we glossed over the crossposting part.

"Just POST to the dev.to API," we said. "How hard could it be?"

Narrator: It was hard.

The Setup

We have a Node.js script that runs daily via GitHub Actions:

// Simplified flow
1. Find all markdown posts with publishAfter <= today
2. Check if they exist on dev.to already
3. If not, create them
4. Send Slack notification

Sounds straightforward. Here are the edge cases that broke it.

Edge Case 1: How Do You Know If a Post Already Exists?

The Problem

We can't just check our local database—we don't have one. The blog is a static site. So how do we avoid posting duplicates?

Naive approach: Keep a .crossposted.json file locally.

Why it fails: Someone manually posts to dev.to. Someone deletes the JSON file. Someone runs the script from a different machine. Duplicates everywhere.

The Fix: dev.to Is the Source of Truth

async fetchDevtoArticles() {
  const response = await fetch(`${DEVTO_API_URL}/me/published?per_page=100`, {
    headers: { 'api-key': this.apiKey },
  });

  const articles = await response.json();

  // Store by canonical_url for O(1) lookup
  for (const article of articles) {
    if (article.canonical_url) {
      this.devtoArticles.set(article.canonical_url, {
        id: article.id,
        url: article.url,
        title: article.title,
      });
    }
  }
}

Before creating anything, we fetch ALL our existing dev.to articles. The canonical_url field is unique—it's the original source URL. If our canonical URL already exists, skip.

Bonus: dev.to returns a 422 error with "canonical" in the message if you try to create a duplicate. We catch that too:

if (response.status === 422 && errorText.toLowerCase().includes('canonical')) {
  return { duplicate: true, title: frontmatter.title };
}

Belt and suspenders.

Edge Case 2: The 60-Day Time Bomb

The Problem

Our script only looks back 60 days on dev.to (performance optimization—we don't need articles from 2 years ago). But what happens to a post with publishAfter: "2025-01-01" that we never crossposted?

Scenario:

January: Write a post, set publishAfter: "2025-01-15"
January 15: Script runs, posts to dev.to ✅
March 20: 65 days later, the script's dev.to lookback window no longer includes this article
Some bug causes the post to be re-processed
Duplicate post on dev.to ❌

The Fix: Auto-Update Stale Dates

If a post has publishAfter older than 60 days, we automatically update it to today:

if (this.isOlderThanDevtoMaxDays(publishAfter)) {
  console.log(`[publish-after] "${title}" has old publishAfter (${publishAfter}), updating to ${today}`);
  return { shouldProcess: true, needsDateUpdate: true, newDate: today };
}

And here's the edge case's edge case—we need to commit this change to git:

// After processing all posts
if (this.filesToCommit.length > 0 && !this.dryRun) {
  commitChanges(this.filesToCommit, 'chore: auto-update old publishAfter dates to today');
}

function commitChanges(files, message) {
  for (const file of files) {
    execSync(`git add "${file}"`, { stdio: 'pipe' });
  }
  execSync(`git commit -m "${message}"`, { stdio: 'pipe' });
}

Why commit? Because if the script runs again before you pull, it would try to update the same posts again. The commit ensures the updated dates persist.

Slack notification: "⚠️ publishAfter updated to today for "My Post" - please pull latest"

Edge Case 3: Accidental Content Overwrites

The Problem

You crosspost a blog post. A week later, you fix a typo locally. The script runs. Does it update dev.to?

If yes: What if you intentionally made dev.to-specific edits? Gone.
If no: How do you push updates when you actually want them?

The Fix: Explicit Update Intent

Updates only happen when you set updatedAt in frontmatter:

---
title: "My Post"
publishAfter: "2026-02-15"
updatedAt: "2026-02-20"  # <-- This triggers the update
---

if (existingArticle) {
  if (frontmatter.updatedAt) {
    // Explicit intent to update - proceed
    result = await this.updateArticle(existingArticle.id, frontmatter, body);
  } else {
    // No updatedAt = skip (don't accidentally overwrite)
    console.log(`[exists] ${frontmatter.title}`);
    continue;
  }
}

No updatedAt? No update. Simple opt-in.

Edge Case 4: dev.to Rate Limiting

The Problem

dev.to allows 10 requests per 30 seconds. Try to crosspost 15 articles at once and you'll hit 429s.

The Fix: Delay + Retry with Backoff

// After each successful post
await new Promise(resolve => setTimeout(resolve, 3500)); // 3.5s delay

// On rate limit (429)
if (response.status === 429 && retryCount < CONFIG.maxRetries) {
  const retryAfter = parseInt(response.headers.get('retry-after'), 10) || 60;
  console.log(`[rate-limited] Waiting ${retryAfter}s before retry...`);
  await new Promise(r => setTimeout(r, retryAfter * 1000));
  return this.createArticle(frontmatter, body, retryCount + 1);
}

3.5 seconds between posts keeps us under the limit. If we do hit a 429, respect the retry-after header and try again.

Edge Case 5: Partial Failures

The Problem

You have 5 posts to crosspost. Posts 1 and 2 succeed. Post 3 fails (network error). What happens to posts 4 and 5?

The Fix: Continue on Failure + Report All

for (const file of files) {
  try {
    result = await this.createArticle(frontmatter, body);
    results.push({ action: 'created', title: frontmatter.title, url: result.url });
    await notifySlack(`Crossposted to dev.to: ${title} → ${result.url}`);
  } catch (error) {
    console.error(`[failed] ${frontmatter.title}: ${error.message}`);
    results.push({ action: 'failed', title: frontmatter.title, error: error.message });
    await notifySlack(`Failed to crosspost "${title}": ${error.message}`, true);
    // Continue to next post - don't abort
  }
}

// Exit with error code if any failures
if (failed > 0) {
  process.exit(1);
}

Every post gets attempted. Every result gets recorded. Every failure gets Slacked. The exit code tells CI whether to retry.

The Complete Slack Notification System

Here's every scenario that triggers a notification:

Event	Emoji	Message
New crosspost	✅	`Crossposted to dev.to: {title} → {url}`
Updated post	✅	`Updated on dev.to: {title} → {url}`
Date auto-fixed	⚠️	`publishAfter updated to today for "{title}" - please pull latest`
Duplicate found	⚠️	`Duplicate on dev.to for "{title}" - already exists, skipping`
Failure	⚠️	`Failed to crosspost "{title}": {error}`

Slack Integration

One environment variable:

export SLACK_JO4_BLOGS_WH="https://hooks.slack.com/services/T00/B00/XXX"

That's it. The script handles the rest:

async function notifySlack(message, isWarning = false) {
  if (!CONFIG.slackWebhook) {
    console.log(`[slack-skip] ${message}`);
    return;
  }

  const emoji = isWarning ? '⚠️' : '✅';
  const text = `${emoji} *Jo4 Blog*: ${message}`;

  await fetch(CONFIG.slackWebhook, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text }),
  });
}

No Slack webhook configured? It logs to console instead. Graceful degradation.

Configuration Knobs

const CONFIG = {
  localMaxDays: parseInt(process.env.LOCAL_MAX_DAYS, 10) || 30,
  devtoMaxDays: parseInt(process.env.DEVTO_MAX_DAYS, 10) || 60,
  maxRetries: 3,
  slackWebhook: process.env.SLACK_JO4_BLOGS_WH,
};

Variable	Default	Purpose
`LOCAL_MAX_DAYS`	30	Only process posts from last X days (unless `publishAfter` is set)
`DEVTO_MAX_DAYS`	60	How far back to check dev.to for existing articles
`SLACK_JO4_BLOGS_WH`	-	Slack webhook URL
`DEVTO_API_KEY`	-	Your dev.to API key (required)

The Full Algorithm

1. Fetch all our articles from dev.to (last 60 days)
   → Store by canonical_url for O(1) lookup

2. For each local markdown file:
   a. Skip if draft or crosspost: false
   b. Skip if publishAfter > today (scheduled for future)
   c. If publishAfter is older than 60 days:
      → Update publishAfter to today
      → Queue file for git commit
      → Slack warning
   d. Check if canonical_url exists on dev.to:
      → If yes AND updatedAt is set: UPDATE
      → If yes AND no updatedAt: SKIP
      → If no: CREATE
   e. Wait 3.5 seconds (rate limiting)
   f. On 429: retry with backoff

3. Commit any auto-updated files to git

4. Report summary + exit code

Lessons Learned

Use the destination as source of truth - Don't maintain local state for external systems
Explicit > implicit - Updates require updatedAt flag, no accidental overwrites
Edge cases have edge cases - Old dates need auto-fixing, auto-fixes need git commits
Fail gracefully - Continue on error, report everything, use exit codes for CI
Integrate Slack early - One webhook URL, five notification scenarios, zero config UI

What edge cases have you hit with crossposting? Every automation has that one bug that only shows up at 3 AM.

Building jo4.io - URL shortener with analytics. Our blog auto-crossposts to dev.to using exactly this system.

5 Hard Lessons from Implementing Zapier OAuth in Spring Boot

Anand Rathnas — Thu, 05 Mar 2026 01:35:06 +0000

Three days. That's how long it took to get a "simple" OAuth integration working with Zapier. The docs made it look easy. Reality had other plans.

Here's what I learned building OAuth 2.0 with PKCE for jo4.io - a URL shortener that now integrates with Zapier, Make.com, and n8n.

Lesson 1: Your OAuth Tokens Fight Your JWT Tokens

Spring Security's filter chain doesn't know the difference between your OAuth access tokens and Auth0's JWTs. Both arrive as Authorization: Bearer <token>. Chaos ensues.

The Problem

OAuth token authentication successful: userId=2, clientId=zapier
...
BearerTokenAuthenticationFilter: Failed to authenticate: Invalid JWT

Wait, what? We just authenticated successfully. Why is it failing?

The JWT filter runs after our OAuth filter and tries to re-validate the same token as a JWT. It fails (obviously - it's not a JWT), and returns 401.

The Fix

Strip the Authorization header after successful OAuth authentication:

@Override
protected void doFilterInternal(HttpServletRequest request,
        HttpServletResponse response, FilterChain filterChain) {

    String token = extractBearerToken(request);

    // Skip if this looks like a JWT (has 3 base64 parts with "alg" header)
    if (isJwtToken(token)) {
        filterChain.doFilter(request, response);
        return;
    }

    try {
        OAuthService.ValidatedToken validated = oauthService.validateAccessToken(token);
        SecurityContextHolder.getContext().setAuthentication(
            new OAuthTokenAuthentication(validated.getUser(), validated.getToken())
        );

        // CRITICAL: Strip header so JWT filter doesn't try to re-validate
        filterChain.doFilter(new AuthorizationStrippingRequestWrapper(request), response);

    } catch (Exception e) {
        sendErrorResponse(response, HttpStatus.UNAUTHORIZED, "invalid_token",
            "The access token is invalid, expired, or revoked");
    }
}

Key insight: Filter chain order matters. Your OAuth filter runs, authenticates, then passes to the next filter. If that next filter sees a Bearer token, it'll try to process it again.

Lesson 2: Concurrent Token Refresh = Race Condition Hell

Zapier's backend makes parallel requests. When a token expires, multiple workers hit your refresh endpoint simultaneously.

The Problem

Thread-1: Refresh token, create new access token A
Thread-1: Revoke old access token (standard practice, right?)
Thread-2: Refresh token, create new access token B
Thread-2: Revoke old access token... wait, that's token A that Thread-1 just created

User sees: "This account is expired. Please reconnect it."

The (Counter-Intuitive) Fix

Don't revoke access tokens on refresh. Let them expire naturally.

public TokenResponse refreshAccessToken(String refreshToken) {
    OAuthRefreshTokenEntity refresh = validateRefreshToken(refreshToken);

    // Create new access token
    String newAccessToken = generateAccessToken();
    saveAccessToken(newAccessToken, refresh.getUserId(), refresh.getClientId());

    // NOTE: We intentionally do NOT revoke old access tokens.
    // This prevents race conditions when multiple concurrent refresh
    // requests would revoke each other's newly created tokens.
    // Access tokens have short lifetimes (1 hour) and expire naturally.

    return new TokenResponse(newAccessToken, refresh.getToken(), 3600);
}

This is standard OAuth 2.0 practice. Access tokens are short-lived by design. Revoking them on refresh is "clever" but breaks under concurrency.

Lesson 3: PKCE Validation Must Be Explicit

@NotBlank on your DTO doesn't always trigger. Bean validation has quirks.

The Problem

Our request DTO:

public record AuthorizeConsentRequest(
    @NotBlank String clientId,
    @NotBlank String redirectUri,
    String scope,
    @NotBlank(message = "PKCE code_challenge is required") String codeChallenge,
    String codeChallengeMethod
) {}

But requests without codeChallenge were getting through. The security bug: attackers could bypass PKCE entirely.

The Fix

Defense in depth - validate explicitly:

@PostMapping("/authorize")
public ResponseEntity<?> authorizeConsent(@Valid @RequestBody AuthorizeConsentRequest request) {

    // SECURITY: Explicit PKCE validation (defense-in-depth)
    if (request.codeChallenge() == null || request.codeChallenge().isBlank()) {
        return errorResponse("invalid_request",
            "PKCE code_challenge is required per OAuth 2.1 security requirements");
    }

    // ... rest of authorization logic
}

Rule: Security validations should be explicit in code, not just annotations.

Lesson 4: Zapier Has Specific Token Response Requirements

The OAuth spec is flexible. Zapier is not.

Requirements I Discovered the Hard Way

Requirement	What I Did Wrong	What Zapier Needs
Token location	Nested in `data` object	Top-level JSON keys
Content-Type	`application/json; charset=UTF-8`	`application/json` works, but verify
`scope` field	Omitted (optional per spec)	Must be present
`token_type`	Returned `Bearer`	Must be exactly `Bearer` (case-sensitive)

Correct response format:

{
  "access_token": "jo4_at_abc123...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "jo4_rt_xyz789...",
  "scope": "read write"
}

Lesson 5: E2E Tests Are Worth the Investment

After two days of "try it and see" debugging, I wrote comprehensive E2E tests. Found three bugs in 10 minutes.

The Concurrent Refresh Test That Found the Race Condition

@Test
void step9_concurrentRefreshDoesNotCauseRaceCondition() throws Exception {
    int concurrentRequests = 5;
    ExecutorService executor = Executors.newFixedThreadPool(concurrentRequests);
    List<Future<ResponseEntity<String>>> futures = new ArrayList<>();

    // Fire 5 refresh requests simultaneously
    for (int i = 0; i < concurrentRequests; i++) {
        futures.add(executor.submit(() -> {
            MultiValueMap<String, String> params = new LinkedMultiValueMap<>();
            params.add("grant_type", "refresh_token");
            params.add("refresh_token", refreshToken);
            params.add("client_id", testClientId);
            params.add("client_secret", testClientSecret);

            return restTemplate.postForEntity("/oauth/token",
                new HttpEntity<>(params, formHeaders), String.class);
        }));
    }

    // ALL must succeed
    for (Future<ResponseEntity<String>> future : futures) {
        ResponseEntity<String> response = future.get(10, TimeUnit.SECONDS);
        assertThat(response.getStatusCode().is2xxSuccessful()).isTrue();
    }
}

This test would have caught the race condition immediately.

TL;DR

Strip Authorization header after OAuth auth succeeds - prevents JWT filter conflicts
Don't revoke tokens on refresh - causes race conditions under concurrent requests
Validate PKCE explicitly - don't trust annotations alone for security
Match Zapier's exact format - tokens at top level, scope included
Write E2E tests first - 10 minutes of tests beats 2 days of production debugging

OAuth looks simple in diagrams. The edge cases will humble you.

What OAuth integration horror stories do you have? I'd love to hear I'm not alone.

Building jo4.io - URL shortener with Zapier, Make.com, and n8n integrations.

How We Solved the Producer-Consumer Problem (For Blog Posts)

Anand Rathnas — Mon, 02 Mar 2026 01:35:15 +0000

You know the producer-consumer problem from computer science, right? One process creates stuff, another process consumes it, and if they're not synchronized, chaos ensues.

Turns out, content creation has the exact same problem.

The Problem: Bursty Writers, Consistent Readers

Here's how blog writing actually works:

Producer (Me):

Monday: Write 4 posts in a caffeine-fueled frenzy
Tuesday-Sunday: *crickets*
Next Monday: Panic, write 3 more posts

Consumer (Readers & SEO):

Expectation: Consistent 3x/week publishing
Reality: 4 posts on Monday, nothing for 2 weeks, then 7 posts on a random Tuesday

Google hates inconsistency. Readers forget you exist. Your newsletter goes from "weekly insights" to "occasional ramblings from someone who may or may not still be alive."

Classic producer-consumer mismatch.

The Traditional Solutions (That Don't Work)

1. "Just Be Consistent"

Ah yes, the "just don't have ADHD" approach. Revolutionary.

The problem isn't motivation—it's that creative energy comes in bursts. Some days you write 3,000 words before breakfast. Other days, you stare at a blank screen and contemplate becoming a goat farmer.

2. Use a CMS with Scheduling

WordPress, Ghost, and others have scheduling. But they require:

Manual date picking for each post
Remembering what you've already scheduled
A calendar that doesn't sync with your actual life
Discipline (see point #1)

3. Hire a Content Manager

laughs in solo developer budget

Our Solution: Stock-Based Scheduling

We built a simple system with one core idea: treat blog posts like inventory.

The Stock File

{
  "_articleStockWouldLastUpto": "2026-02-26",
  "getting-started-with-jo4": "2026-01-31",
  "api-first-url-shortener": "2026-02-03",
  "claude-code-hooks": "2026-02-05",
  "elasticache-vs-memorydb": "2026-02-07"
}

Each post gets a publishAfter date in its frontmatter. The stock.json file tracks everything:

What's scheduled
When each post goes live
When you'll run out of content

That last field—_articleStockWouldLastUpto—is the magic. It's your inventory level.

The Workflow

When I write (producer):

Create post with content
Set publishAfter to the next available slot
Update stock.json with the new entry
Update _articleStockWouldLastUpto if this is the latest

When GitHub Actions runs (consumer):

Check which posts have publishAfter <= today
Build and publish those posts
Crosspost to dev.to
Check stock levels

The Low Stock Warning

Here's the clever bit. Every day at 1 AM UTC, our CI pipeline checks:

STOCK_DATE=$(jq -r '._articleStockWouldLastUpto' stock.json)
DAYS_LEFT=$(( (STOCK_EPOCH - TODAY_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt 3 ]; then
  echo "LOW STOCK! Only $DAYS_LEFT days remaining!"
  # Send Slack notification
fi

If I have less than 3 days of content queued up, I get a Slack message:

It's like a grocery store inventory system, but for words.

Why This Works

1. Decouples Writing from Publishing

I can write 5 posts on a Sunday afternoon and not worry about when they'll go live. The system handles the "when," I handle the "what."

2. Visualizes the Buffer

Seeing _articleStockWouldLastUpto: "2026-02-26" is motivating. It's concrete. "I have 25 days of content" is way more actionable than "I should probably write more."

3. Prevents Feast-or-Famine

The warning system catches problems before they become crises. No more "oh no, I haven't posted in 3 weeks" panic.

4. Works with Bursts

Write 10 posts in a weekend? Great, you just bought yourself a month. The system doesn't care when you write, just that you eventually do.

The Implementation

Post Frontmatter

---
title: "My Post Title"
description: "SEO-friendly description"
blogPath: my-post-slug
publishAfter: "2026-03-02"
author: Jo4 Team
tags:
  - tag1
  - tag2
  - tag3
  - tag4
---

The publishAfter field is the key. Posts with future dates exist in the repo but aren't built into the public site.

Build Logic

// In 11ty config
eleventyConfig.addCollection("posts", function(collection) {
  const today = new Date().toISOString().split('T')[0];
  return collection
    .getFilteredByGlob("posts/**/index.md")
    .filter(post => post.data.publishAfter <= today)
    .sort((a, b) => b.data.publishAfter.localeCompare(a.data.publishAfter));
});

Future posts are filtered out at build time. Simple.

GitHub Actions Cron

schedule:
  - cron: "0 1 * * *"  # Daily at 1 AM UTC

The pipeline runs daily, checks for newly-eligible posts, builds, deploys, and crossposts.

The Meta Irony

Yes, I'm writing a blog post about automating blog posts.

Yes, this post will be scheduled using the system I'm describing.

Yes, I wrote this during a burst of productivity and it's scheduled 3 weeks out.

The system works.

Lessons Learned

Treat creative work like inventory - Buffers smooth out inconsistency
Automate the boring parts - Date calculation, crossposting, warnings
Make the invisible visible - _articleStockWouldLastUpto turns abstract anxiety into concrete numbers
Design for how you actually work - Bursts are fine if the system handles them

Try It Yourself

The full system is:

11ty for static site generation
GitHub Actions for scheduling and deployment
A simple JSON file for inventory tracking
Slack webhook for low-stock alerts

Total lines of custom code: ~50.

Sometimes the best solutions aren't frameworks or SaaS products. Sometimes it's just a JSON file and a cron job.

How do you handle content scheduling? Built your own system, or using something off-the-shelf?

Building jo4.io - URL shortener with analytics. Yes, we practice what we preach with consistent publishing.