Jo4 Is Now on Zapier: From Design Doc to Live in 5 Weeks

· 9 min read · Jo4 Team
zapier automation buildinpublic saas

Jo4 is officially live on Zapier. The whole thing — from first design doc to approved listing — took about five weeks. Two weeks of building, one day of thinking "this will be quick," and two more weeks of review that almost ended in a closed ticket.

Here's the full timeline.

Weeks 1–2: Building the Integration

Before you can even submit to Zapier, there's a mountain of requirements to meet. We found this out the hard way by reading through their publishing guidelines. Here's what we had to build and prepare.

The Authentication Problem

Zapier strongly prefers OAuth v2. They accept API key auth, but OAuth is the path of least friction during review. We went with OAuth2 + PKCE — the same flow we already use for our own frontend.

The catch: Zapier only supports the authorization_code grant type. If your API uses client_credentials, you're stuck with Session auth instead. We were fine here, but it's worth checking before you start building.

Every endpoint has to be HTTPS. No exceptions. No sandbox or dev URLs either — Zapier wants production endpoints only. We also needed a dedicated /api/v1/zapier/me endpoint for Zapier to verify credentials during the auth test step.

REST Hooks, Not Webhooks

This one surprised us. Static webhooks are not allowed in public Zapier integrations. You have to implement REST Hooks — Zapier's subscribe/unsubscribe pattern where they POST a hookUrl to your API, and you fire payloads to that URL when events happen.

That meant building:

  • POST /api/v1/zapier/hooks/url-created — subscribe to the trigger
  • DELETE /api/v1/zapier/hooks/{id} — unsubscribe
  • GET /api/v1/zapier/urls/recent — polling fallback for sample data in the Zap editor

The polling endpoint was easy to overlook. Zapier needs it to show users sample data when they're configuring a Zap, and the data format has to exactly match your hook payloads. We got this wrong on the first attempt — the polling response had slightly different field names than the webhook payload. That kind of mismatch will get flagged in review.

Trigger and Action Design

We shipped with one trigger (New Short URL Created) and one action (Create Short URL). Minimal, but functional.

Zapier's naming conventions are strict. Triggers must be title-cased ("New Short URL Created" not "New short url created"). Descriptions must follow the format "Triggers when [action]." — no app name, no capitalized nouns. Action descriptions start with third-person verbs: "Creates a new short URL."

Field labels use sentence case. You can't label a field "URL ID" and expect users to type an ID — you need dynamic dropdowns. Help text is only for genuinely ambiguous fields; don't over-annotate.

Output data has its own rules: dates must be ISO 8601 with timezone offsets, booleans must be true/false (not 1/0), and you should return the full created resource — not just a success message.

The Pre-Submission Checklist

Before hitting submit, Zapier requires:

  • App must be publicly launched. No invite-only betas.
  • API documentation must be live and comprehensive. They check.
  • Logo, description, homepage URL, and category all need to be set in the Zapier Platform dashboard.
  • At least one admin with an email matching your app's domain. Not your parent company domain. This tripped us up later.
  • All user-facing text in English. Trigger names, field labels, help text, error messages — everything.
  • Integration fully tested with real Zaps. Every trigger and action needs at least one successful run in your Zap history. They may ask to see it.
  • Don't delete your test Zaps. Zapier's review team might request access.

We spent about two weeks building the endpoints, writing the Zapier CLI app, testing everything with live Zaps, and going through the naming conventions doc line by line. On January 19th, we hit submit.

The Review: 14 Days

Day 1: The Submission

Code was solid. OAuth2 with PKCE, REST hooks wired up, polling endpoint matching the hook payloads, test Zaps all green. I hit submit and figured we'd be live within a week.

Famous last words.

Day 1 (Still): The First Reply

Zapier's team moved fast. Within hours, their Partner Support reached out asking about a mismatch — our integration was named Jo4 but the homepage pointed to rathnas.com. Fair question. Jo4 is a product by Rathnas LLC. The homepage URL needed to point to jo4.io, not the parent company. Easy fix.

Except I never saw the email.

Days 2–9: The Silence

Gmail's spam filter had other plans. Zapier's replies went straight to spam. I had no idea they were waiting on me.

They sent a follow-up on day 3. Then another on day 7 — this one saying they'd close the ticket if I didn't respond.

I was sitting there thinking "why is the review taking so long?" while their emails were rotting in my spam folder.

Day 9: The "Oh No" Moment

I finally found the emails on January 28th. The ticket was about to be closed. I fired off a reply explaining the Rathnas/Jo4 relationship, with a link to our case studies page.

Narrator: The panic was real.

Day 11: The Review Checklist

A second reviewer stepped in and sent a detailed 5-point checklist. This is where it got real:

1. Test account needed. They wanted a non-expiring account for their QA team. No trial limitations, all paid features enabled. Created one immediately.

2. Integration description had grammar issues. My original description said "a enterprise tool to for SDRs." Yeah. Typos in your integration description are not a great look.

3. Homepage URL was wrong. Still pointing to rathnas.com instead of jo4.io.

4. Admin email needed to match the app domain. My admin was using the parent company's email — they needed someone with a @jo4.io address. Added [email protected] as admin.

5. Field naming conventions. App names in trigger field descriptions are a no-no. Cleaned those up.

Five items. All fixable in under an hour. But they wouldn't have been necessary if we'd read the requirements more carefully before submitting.

Day 12: All Items Resolved

Sent everything back the next morning. Test credentials, updated description, corrected homepage, domain-matched admin, cleaned field names. All five checkboxes green.

Then waited.

Day 14: Approved

The integration was approved and published on February 2nd.

14 days from submission to live. Realistically, it would have been 3 days if my spam filter hadn't eaten the initial emails.

What You Can Do With Jo4 + Zapier

The integration is live at zapier.com/apps/jo4io/integrations. Here's what's available:

Triggers

  • New Short URL Created — fires whenever someone creates a short link in jo4. Use this to log new links to Google Sheets, notify your team in Slack, or sync with your CRM.

Actions

  • Create Short URL — create a jo4 short link from any Zapier workflow. Shorten links automatically when a new blog post is published, a form is submitted, or a deal closes in your CRM.

Example Zaps

Trigger Action Use Case
New WordPress post Create jo4 short URL Auto-generate trackable short links for every blog post
New Typeform submission Create jo4 short URL Shorten confirmation page links with UTM tracking
New jo4 URL created Send Slack message Notify your team when new campaign links are created
New jo4 URL created Add row to Google Sheet Build a running log of all your short links

Lessons for Other Indie Hackers Submitting to Zapier

Before You Build

  1. Use OAuth v2 if you can. API key auth works, but OAuth is what Zapier prefers and it makes the review smoother.

  2. Implement REST Hooks, not static webhooks. Static webhooks are rejected in public integrations. Build proper subscribe/unsubscribe endpoints.

  3. Your polling endpoint data must match your hook payloads exactly. Different field names or formats between the two will get flagged.

  4. Read the naming conventions doc before writing a single field label. Title case for trigger/action names, sentence case for field labels, no app name in descriptions. It's tedious but reviewers check every field.

  5. Have your API docs live and public. Zapier's team will check the links you provide.

Before You Submit

  1. Use your product domain for everything. Homepage URL, admin email, description — all should reference your product domain, not your parent company.

  2. Set up a test account for [email protected]. Non-expiring, all features enabled, including paid ones. Do this before you submit.

  3. Test every trigger and action with a real Zap. At least one successful run per trigger/action. Don't delete the test Zaps — reviewers might ask to see them.

  4. Proofread your integration description. It's literally the first thing reviewers see.

During Review

  1. Check your spam folder. Zapier's support emails can land in spam. Add their domains to your allowlist before submitting.

  2. Respond to review emails within 48 hours. They will close your ticket after a week of silence. Check daily.

What's Next

The Zapier integration is v1.0.0. We're already planning additional triggers (link clicked, link expired) and actions (update URL, bulk create). If there's a specific workflow you'd like to automate with jo4, let us know.

After approval, Zapier puts your integration into a 90-day beta phase. The goal: 50 active users and at least 10 published Zap Templates. We're working on both.

Already using Zapier? Try the jo4 integration and tell us what workflows you build. We're genuinely curious.

Building jo4.io — modern URL shortener with analytics, now with Zapier automation baked in.