DEV Community: Pratham Israni

A jobs API with 1M live listings, straight from company career pages

Pratham Israni — Tue, 20 Oct 2026 08:42:04 +0000

I started this for myself. I wanted the open roles at every big company in one place, without visiting hundreds of career pages. It now holds about 1 million live jobs from 35,000+ companies, and it's on RapidAPI.

The jobs aren't scraped from job boards. They come from the employers' own career-site platforms (Greenhouse, Lever, Ashby, Workday, SmartRecruiters and 20 more sources), so every applyUrl points to the company's own application page. A nightly refresh adds new postings, about 30,000 a day, and drops the ones that have closed.

The filters are the reason it exists

The job-search APIs I compared filter by keyword, location and sometimes experience, but not by department or category. I wanted to ask for "senior DevOps, remote, open to people in India" and get exactly that. So this one has 19 categories with 114 subcategories, five experience levels, country, state and city, remote, hybrid or onsite, keyword include and exclude, company, source, and posted-within-days.

curl --request GET \
  --url 'https://company-career-sites-jobs-api1.p.rapidapi.com/api/public/v1/jobs?categories=DevOps%2C%20Cloud%20%26%20Infrastructure&experienceLevels=Senior&countries=India&workModes=remote&limit=2' \
  --header 'x-rapidapi-host: company-career-sites-jobs-api1.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_KEY'

Each response carries a nextCursor. Pass it back as cursor to get the next page.

One edge case to know about: remote jobs that are open to anyone, anywhere, have no country, so a country filter drops them. includeWorldwideRemote=true brings them back, and includeUnspecifiedLocation=true does the same for jobs that list no location at all.

The database took three tries

At first the data lived in GitHub JSON files inside an app, and the first load took far too long. I moved it to Supabase, hit the 500 MB limit, and queries slowed down as the data grew. Now it's Postgres on an Oracle VM with more RAM and storage, and queries are very fast. Getting the VM took a workflow of its own. One filtered India query needed about 3 seconds until I added indexes on the lowercased columns; it now runs in under half a second.

If your dataset is heading toward a million rows, start on the machine you'll end up on. I paid for two migrations to learn that.

What it isn't

It isn't every job on the internet. Aggregators that index the whole web have a bigger catalogue than mine, and if that's what you need, use one. This is the opposite trade: about 1M jobs, all from employers' own pages, with filters that go further. There is no UI and nothing decorative, only structured data.

That suits a new job board filling its first listings, a niche board that needs a backfill for one category and region, or an alert tool that watches one filter every morning. Checking company pages by hand every day takes hours. One call replaces it.

On RapidAPI each call returns up to 10 jobs plus a cursor, which works for search, alerts and filling a niche. If you need the whole index, the same data is available on Apify, billed per result.

There's a free Basic plan to try it: Company Career Sites Jobs API on RapidAPI.

Moving 530k Jobs from Supabase to Postgres on a Free Oracle VM (14s -> 47ms)

Pratham Israni — Sat, 10 Oct 2026 06:12:05 +0000

I built a job feed. It pulls jobs straight from company career pages into one searchable list. No login, no redirects through job boards.

In a few months it grew from 10,000 jobs to over 530,000. Every time the number jumped, something broke. Here's what broke and how I fixed it.

Career pages, then ATS platforms

I started by writing a scraper for each company's career page. One company, one scraper. Slow.

Then I noticed most companies don't build their own job board. They use an applicant tracking system (ATS) like Greenhouse, Lever or Ashby, and these have public job data. One integration covered thousands of companies. The count went 10.5k → 16.5k → 100k → 300k → 530k, and it's still growing.

GitHub as the database

At first, GitHub was my database. A scheduled GitHub Action fetched jobs, saved one JSON file per company, and committed it. The site read those files. Free, versioned, nothing to manage.

Up to around 100k jobs, it was fast.

The problem: a browser can only filter data it already has. So the first load had to download everything. As data grew, first paint went to 13–15 seconds. Filters were instant after that, but nobody waits 15 seconds to see them.

Moving to Supabase

So I moved to Postgres on Supabase. The GitHub Action synced data into it every night. The page loaded 50 jobs at a time, and filters became SQL queries.

First load got better. But every filter now took 5–7 seconds. Then at 530k jobs, the database crossed the 500 MB free limit.

When I checked, two queries were the real problem: counting all jobs, and grouping jobs by company for the filter list. Each took about 14 seconds. That's not Supabase's fault. A small shared free instance just isn't made to scan half a million rows on every request.

Getting a free Oracle server

Oracle Cloud's free tier gives you an ARM server with up to 2 cores and 12 GB RAM. For a 532 MB database, that's more than enough.

But it's hard to get. Every time I clicked Create, I got:

Out of host capacity

Instead of refreshing all day, I wrote a script. It calls the Oracle CLI to create the server, and if the error is "no capacity" or a rate limit, it waits and tries again. A GitHub Action ran it every few minutes.

for i in 1 2 3 4 5; do
  timeout 60 oci --no-retry compute instance launch ... && break
  sleep 20
done

It failed 124 times overnight. The 125th try worked, and I woke up to a free 12 GB server in Mumbai.

Setting up Postgres

The next morning, it took me about 3–4 hours to get Postgres running on the new VM and start syncing the data.

I ran one or two of the slow queries on it, and that was enough to convince me. I quickly pointed Vercel and my Cloudflare Worker (which serves my public API) to the new database and tested the site.

The results were mind-blowing.

The result

Same queries, run directly on each database:

Query	Supabase (free)	Oracle VM
Count all jobs	13.7 s	26 ms
Group jobs by company	13.9 s	47 ms
Keyword search	177 ms	5.5 ms
First page of results	22 ms	0.3 ms

In the browser, pages that took 16–48 seconds now load in under a quarter second.

To be fair, a lot of this is hardware. The whole database now fits in memory on a 12 GB machine, while the free instance was small and shared. Same Postgres, just more room.

What I learned

Find the slow query before blaming the platform. Two queries caused almost everything.
Check what a free tier actually limits. Mine capped storage, but compute is what hurt.
If you have to wait for something, let a script do the waiting.

You can try the job-feed here (non-profit): link.
If you want the data in your own app, it's also on Apify as an API: link.

My keyword search took 5 seconds over 355k jobs, and C++ matched random jobs

Pratham Israni — Sun, 04 Oct 2026 18:26:51 +0000

I'm building a searchable index of about 310,000 open jobs from roughly 6,800 company career pages, mostly Indian IT and services firms. Most of them publish their openings through public job feeds, so I pull from those.

The 5-second search

My first keyword search used ILIKE over title and company. On 355k rows, EXPLAIN ANALYZE showed a full sequential scan at about 5 seconds, which is too slow for a search box.

Trigram indexes fixed the speed but used too much storage on the free tier. I switched to a GIN index over to_tsvector('simple', ...). I chose simple over english because english stems words and drops stopwords, which makes results hard to predict.

The C++ problem

With the new index, searching for C++ returned unrelated jobs. Postgres reduces C++ to a bare c token under both text configs, and .NET to net. So a C++ search matched anything with a standalone "c" in it.

The fix is a normalization step applied on both sides of the search:

c++ → cpp
c# → csharp
.net → dotnet

It runs in the index expression and in the query builder, so they stay in sync. The catch is that these rules live in two places, and I have to keep them matching by hand.

Rate limiting, what didn't work

My first limiter was a globalThis Map on Vercel. Every cold start reset it, so it wasn't really a limit. Cloudflare's native rate-limit binding didn't enforce for me either. I sent 220+ requests and got zero 429s.

A Durable Object keyed by API key (idFromName(apiKey)) worked. It started returning 429 around request 62, and other keys weren't affected.

Hyperdrive setup gotchas

Use Supabase's direct connection (port 5432). Hyperdrive does its own pooling.
Use one pg Client per request.
On Supabase, GRANT postgres TO hyperdrive_user isn't allowed. I granted scoped SELECT and added an RLS policy for that role only.

What it doesn't do

No job descriptions. Title, company, location, apply link, and dates only.
Refreshes about once a day. Each row has lastSeenAt.
About a third of rows have no city.
No salary. The sources don't publish it consistently.

If you've run a similar setup, I'd like to know how you handled keyword search over a large table without a trigram index.

The Actor is here if you want to look at the data: https://apify.com/pk07007/ats-jobs-api

Sonner vs. robot-toast: When "Invisible" UI Isn't Enough

Pratham Israni — Thu, 14 May 2026 02:15:00 +0000

I used Sonner for almost everything before robot-toast existed.

Genuinely liked it. Clean, premium, gets out of the way. You fire a toast, user gets the info, nobody thinks twice about it. Invisible by design and that's not a criticism, that's exactly what it's built for.

react-hot-toast is the same philosophy but even more minimal. No config, no setup, just works. If you want something running in 30 seconds, that's your library.

Toastify is the opposite, it's been around forever, has every feature you could possibly need, and the bundle size shows it. It's the jQuery of toast libraries. Still used everywhere for a reason.

But then I noticed something while building my portfolio and working on a startup. Platforms like Codolio, CodeChef, Coding Ninjas — they all have a distinct personality. You feel it the moment you land. The colors, the tone, the micro-interactions. Everything is intentional.

And then a toast pops up. A plain rectangle. No personality. Like a different product showed up for two seconds and left.

That's where thought of making robot-toast came from.

Sonner is still my recommendation if you want invisible notifications. react-hot-toast if you want zero friction. Toastify if you need every feature possible.

robot-toast is for when invisible isn't enough, when your product has a personality and your notifications should too.

package: npm i robot-toast
playground: robot-toast.vercel.app

I never expected this response ~robot-toast

Pratham Israni — Fri, 08 May 2026 09:43:07 +0000

It started with an SSO project.

I was building an IDP server — the kind that handles authentication across connected domains. I wanted a Google-like widget, the one that shows up and says "Hey, you switched accounts" or "Welcome back, Pratham." Clean. Branded. Satisfying.

So I built a toast that shipped via a script tag directly from my IDP server. It worked. But it was rigid, tightly coupled to my server, and offered almost zero flexibility for anything outside that one use case.
That bothered me.

So I asked myself — what if the toast could live anywhere, independent of my server? What if any project could use it?
That's when I found out you can just... make your own npm package. I set a target of one night. And in that one night, robot-toast@1.0.0-beta.0 was born.
I have no idea why I made them robots. It just felt right.

I built a playground to see how it looked from the outside. Posted it on Reddit, LinkedIn, sent it to some friends. People had opinions. Good ones, bad ones, weird ones. I shipped fixes on weekends, mostly when I felt like it. No roadmap. No deadlines.
Two months later, v2.1.9. Sixteen variants. Four themes. Zero dependencies. A React hook. SSR safe.
And somewhere along the way — 3,200 downloads. More traction than the SSO project that started the whole thing.

Here's the thing I want to be honest about: I didn't build this for you.

I built it because I needed it.
I open-sourced it because why not.
I maintained it because the feedback was interesting, not because I felt obligated. There's no company behind it, no roadmap, no monetization plan.

If you use it and love it — genuinely happy about that.
If you use it and curse at it — valid, open a GitHub issue.
If you never use it — also completely fine.

That detachment, weirdly, made it better. Every update came from real curiosity, not pressure.

If you want robots in your notifications - robot-toast demo , use npm i robot-toast
If not, I hope your toast library of choice brings you peace.

I Built a Toast Library Where a Robot Delivers Your Notifications 🤖

Pratham Israni — Thu, 23 Apr 2026 16:39:17 +0000

Every React app needs toast notifications. So there are roughly a thousand toast libraries on npm.

I built another one. But this one has a robot.

Why though?

I was building a side project and dropped in react-toastify. Functional. Totally forgettable. Then tried sonner — cleaner, but still just a rectangle sliding in from the corner.

I wanted something that actually made users presents my persona on my site when something happened in the app. So I built robot-toast.

What started as a weekend experiment is now a full-featured, production-ready library at v2.1.5 — 21 published versions, a demo playground, tests, and actual downloads from people I don't know.

What makes it different

Most toast libraries compete on the same axis: bundle size, API ergonomics, animation smoothness. robot-toast does all of that, but the actual differentiator is that you can customize everything in your own way and bring personality to your product, and to get you a headsup, robot-toast comes with 16 robot variants.

It sounds gimmicky. It isn't. Here's why it works:

Error states feel less brutal when a robot looks flustered instead of a red bar flashing
Success feels genuinely rewarding when the robot waves
Users notice and remember it — which matters for apps where UX polish is a competitive edge

The full feature set (v2)

npm install robot-toast

Basic usage

import { toast } from 'robot-toast';
import { wave } from 'robot-toast/robots';

toast('Hello world');
toast.success('Saved!');
toast.error('Something broke');
toast({ message: 'Custom robot!', robotVariant: wave });

16 tree-shakeable robot variants

angry, angry2, shock, think, search,
loading, sleep, headPalm, typing,
validation, validation2." width="561" height="636">

Each robot is a separate subpath export. You only ship the ones you use — no dead SVG weight in your bundle.

You can also pass any custom SVG/PNG/GIF path:

toast({ message: 'Custom!', robotVariant: '/my-mascot.svg' });

toast.promise()

toast.promise(fetch('/api/save').then(r => r.json()), {
  loading: 'Saving…',
  success: (data) => `Saved as ${data.name}`,
  error: (err) => `Failed: ${err.message}`,
});

One of my favourite patterns. Attach loading/success/error states to any promise in a single call. No managing state yourself.

Typewriter effect

toast({ message: 'Deploying your app…', typeSpeed: 30 });

The message types out character by character. I haven't seen this in any other toast library. Small touch, weirdly satisfying to watch.

Custom action buttons

toast({
  message: 'File deleted',
  buttons: [
    { label: 'Undo', onClick: () => restoreFile() },
    { label: 'Keep', onClick: () => {}, style: { color: 'gray' } },
  ],
});

No limit on number of buttons. Most libraries restrict you to one action and one cancel.

Full options

toast({
  message: 'Notification text',
  type: 'default' | 'info' | 'success' | 'warning' | 'error',
  theme: 'light' | 'dark' | 'colored',
  transition: 'bounce' | 'flip' | 'zoom' | 'slide',
  position: 'top-left' | 'top-center' | 'top-right' |
            'bottom-left' | 'bottom-center' | 'bottom-right',
  autoClose: 5000 | false,
  typeSpeed: 30,
  hideProgressBar: false,
  draggable: true,
  pauseOnHover: true,
  pauseOnFocusLoss: true,
  nearScreen: true,
  rtl: false,
  style: { background: '...', color: '...' },
  onOpen: () => {},
  onClose: () => {},
});

Framework-agnostic core

The core library has no framework dependency. React is an optional peer dependency.

// Vanilla JS
import { toast } from 'robot-toast';
toast.success('Works anywhere');

// React hook
import { useRobotToast } from 'robot-toast/react';

function App() {
  const toast = useRobotToast();
  return <button onClick={() => toast.success('Saved!')}>Save</button>;
}

Works with React, Next.js, Vue, Angular, Svelte, vanilla JS — one install, no adapter packages.

Accessibility

This part I'm genuinely proud of:

error / warning toasts: role="alert" + aria-live="assertive" — announced immediately
Other types: role="status" + aria-live="polite" — announced at next opportunity
aria-atomic="true" — full message re-announced on update
Labeled close button for screen readers

Most indie toast libraries treat a11y as an afterthought. I didn't want to do that.

Comparison with the popular ones

	robot-toast	Sonner	react-toastify	react-hot-toast
Framework agnostic	✅	❌	❌	❌
Animated character	✅	❌	❌	❌
Typewriter effect	✅	❌	❌	❌
Unlimited buttons	✅	❌	✅	❌
toast.promise()	✅	✅	✅	✅
Zero prod deps	✅	✅	✅	✅
Tree-shakeable assets	✅	N/A	N/A	N/A
Full a11y	✅	✅	✅	partial

Sonner is the dominant player right now and it deserves to be — the stacking animation and shadcn integration are excellent. robot-toast isn't trying to replace it. It's for the apps where personality matters.

Programmatic control

const id = toast('Working…');

// Update it
toast.closeById(id);

// Dismiss everything
toast.closeAll();

Try it

Demo & playground: robot-toast.vercel.app
npm: npmjs.com/package/robot-toast
GitHub: github.com/Pratham2703005/robot-toast-package

npm install robot-toast

If you use it, drop a comment — I'm genuinely curious what people build with it. And if something's broken or missing, open an issue. v2 exists because of feedback on v1.