I built a Zapier integration for my solo SaaS. Here's every decision I made

I am a full-stack software engineer in Durban, South Africa. I work full-time and build SaaS products after hours. PayChasers is one of them. It's a payment chasing tool for anyone who's owed money and tired of asking twice.

Today I submitted it to Zapier's partner program. Here's exactly how it went and what I would do differently.

What PayChasers does

PayChasers handles chasing payment reminders for invoices, rent, deposits, failed payments, and personal debts — anything where someone owes you money and you'd rather not send awkward reminders yourself.

You add a chase. You choose how to handle it. Send a follow-up manually when you're ready, or turn on Auto Chase and let PayChasers handle the escalation for you: friendly nudge, due today, overdue, firm. Email or WhatsApp. The tone sharpens as the payment ages. You stay in control of every message. Nothing goes out without your templates, your tone, your timing.

It works. But the product lives in isolation. If someone tracks invoices in Google Sheets, manages deals in HubSpot, or processes payments through Stripe, they have to manually create chases in PayChasers. That's friction. Friction kills adoption.

So I built a Zapier integration.

Why Zapier and not direct integrations

I considered building native integrations. A Stripe webhook listener, a Google Sheets sync, a HubSpot connector. Each one would take days. Each one adds a maintenance surface. Each one serves one app.

Zapier serves 7000+ apps with one integration.

I built one API surface and let Zapier be the bridge. A user who wants "Hubspot deal closes -> create a chase in PayChasers" can build that in 2 minutes without me writing a single line of HubSpot code.

The trade-off is control. I can't fine-tune each experience. But for a solo engineer, the leverage is hard to beat.

What the integration exposes

Triggers (things that happen in PayChasers)

• New Chase - fires when a user creates a chase
• Chase Overdue - fires when a chase passes its due date
• Chase Paid - fires when a chase is marked as paid
• Follow-up Sent - fires when an automated follow-up email goes out

Actions (things Zapier can do in PayChasers)

• Create Chase - create a new chase with client details, amount, due date, currency, and chase type
• Send Follow-up - trigger a follow-up on an existing chase
• Mark as Paid - mark a chase as paid

Auth

API key authentication. Users generate a key in Settings, paste it into Zapier. Simple, no OAuth dance. The key is hashed with SHA-256 before storage. I never see the raw key after it's generated.

The API layer

I built a /api/v1/ REST API specifically for this. It's separate from the internal app routes. Endpoints:

GET    /api/v1/me                   — verify auth
GET    /api/v1/chases               — list chases
POST   /api/v1/chases               — create a chase
POST   /api/v1/chases/:id/paid      — mark paid
POST   /api/v1/chases/:id/follow-up — send follow-up
GET    /api/v1/clients              — list clients
GET    /api/v1/triggers/*           — polling triggers for Zapier

The triggers use Zapier's polling model. Zapier hits the trigger endpoint every few minutes, and I return items sorted by most recent. Zapier deduplicates by ID.

I considered webhooks (Zapier's REST Hook model) but polling was simpler to implement and doesn't require me to manage subscription state. For a product at my scale, polling every few minutes is fine and I dont see any issues.

The embed strategy

Zapier offers a "Full Zapier Experience" embed. A JavaScript widget that lets users discover and build "Zaps" directly inside your app. I built the page for it but designed it with two states:

Before approval: An informational page explaining whats coming. no dead UI, no broken embed. Just a clear explanation of what Zapier automation enables and what it will look like.

After approval: Set one environment variable (NEXT_PUBLIC_ZAPIER_FZE_CLIENT_ID), ready to redeploy and the embed loads. Users can browse Zap templates and build automations without leaving PayChasers.

Zero code changes needed when the switch flips. One env var.

Ref-based signup attribution

This is the part I almost skipped and I am glad I didn't.

When someone clicks through from a Zap template to sign up, I wanted to know which template drove them. So the signup page accepts a ?ref= parameter:

• /signup?ref=zapier-stripe → "Chase failed Stripe payments automatically."
• /signup?ref=zapier-sheets → "Turn your spreadsheet into a payment chasing machine."
• /signup?ref=zapier-hubspot → "Close the deal. Chase the payment. Automatically."
• /signup?ref=zapier-forms → "From form submission to follow-up in seconds."
• /signup?ref=zapier → "Automate your payment follow-ups."

Each ref swaps the hero headline and subtitle on the signup page. The person sees copy that matches their intent.

The ref is also stored on the user record in the database as signupRef. After 30 days of beinfg live I can run:

SELECT signupRef, COUNT(*) FROM "User"
WHERE signupRef IS NOT NULL
GROUP BY signupRef
ORDER BY count DESC;

That tells me which integration is driving signups, which use case resonates, and where to double down in listing copy. Without it, I would know signups are happening but not why.

One column. Massive signal.

The partner review process

Submitting to Zapier's partner program is straightforward but not instant. Here's how it went:

1. Build the integration on Zapier's developer platform
2. Submit for review. Their team assigns a reviewer.
3. Compliance check. The reviewer checked my homepage, terms of service, and privacy policy to confirm the country of operation. He couldn't find it. Fair, it wasn't there.
4. Fix and respond. I added "South Africa" to my Terms of Service, Privacy Policy, and Contact page within the hour. Updated the Governing Law clause to reference South African law.
5. Wait for Beta. After passing review, the integration moves to Beta in the Zapier app directory.

The compliance ask caught me off guard but makes sense. They're publishing your app in their directory, they need to know where you operate.

If you're building a Zapier integration, put your country and legal jurisdiction on your site before you submit. Save yourself a round trip.

What I would do differently

Start with the API earlier. The /api/v1/ layer is clean and useful beyond Zapier. It could serve a mobile app, a CLI, or any other client. I should have built it as a first-class citizen from day one instead of bolting it on for Zapier.

Don't overthink trigger architecture. I spent time debating polling vs webhooks. Polling is fine. Ship it. You can add webhooks later if scale demands it.

Add signup attribution from the start. The signupRef field took 10 minutes to add. It should have been there from the first signup form.

Put your legal jurisdiction on your site from day one. Not just for Zapier, for any partnership, integration, or compliance review. It took me an hour to fix. It should have been there from the start.

Current status

PayChasers has paying users across multiple countries. We are early, but the signal is real.

The integration has been submitted and is in review. The embed page is built and waiting. The attribution tracking is live. When the green light comes, it's one env var and a deploy.

If you're an indie hacker thinking about integrations, Zapier is high leverage. One integration surface, thousands of connections. Build the API, submit the integration, track your refs, and let the platform do the distribution.

I am Simangaliso, building PayChasers from South Africa. If you've ever sent a "just following up" email manually, PayChasers was built for you. paychasers.com