[NewSearch millions of jobs from your AI agent with MCP→](/blog/jobspipe-mcp-server) [All posts](/blog) Comparison·Jul 22, 2026·10 min read # Unified API platforms: the two kinds, and which one job data needs The unified API category contains two products that get confused constantly - one reads your customer's systems with their credentials, the other reads public data nobody has to authorize. They solve different problems, fail in different ways, and only one of them can answer 'who is hiring right now'. Which platforms sit where, and how to tell which you actually need. ![Dvir Atias](/authors/dvir-atias.jpg) Dvir Atias Founder, JobsPipe “Unified API” is one label covering two products that solve genuinely different problems. Teams evaluate them side by side, pick the wrong one, and discover the mismatch a month into integration - usually at the moment someone asks a question the chosen platform structurally cannot answer. The dividing line is simple once you see it: **whose data is it, and who has to authorize access**. For the short definition of the category, see the [unified API glossary entry](/glossary/unified-api). This post is about choosing between the two kinds. ## Kind 1: customer-credential unified APIs Merge, Nango, Apideck, Paragon and similar platforms let your product read data out of _your customer’s_ systems. Your user connects their Greenhouse, Workday or BambooHR account through an OAuth flow, and you get their candidates, employees or requisitions through one normalized schema instead of writing an integration per vendor. **What it is for:** B2B SaaS that needs customer-facing integrations. If you are building a recruiting analytics tool and your customer wants to see their own pipeline, this is exactly right. **The structural limit:** you can only ever see data for customers who connected an account. There is no way to answer “which companies are hiring Rust engineers this week”, because you have no relationship with those companies and they have not authorized you. The product is not failing when it cannot do this - it was never the design. ## Kind 2: public-data unified APIs The other kind normalizes data that is already public. Nobody grants access, because nothing is private. For job postings that means the listings companies publish on their career sites, ATS boards and job boards, collected and mapped into one schema. **What it is for:** anything that needs a market view rather than a customer view - sourcing tools, hiring-signal sales products, market research, job boards, and agents that answer questions about who is hiring. This is the category the [JobsPipe API](/jobs-api) sits in. **The structural limit:** you only see what is published. Internal requisitions, candidate pipelines, salary bands that never appear in a posting, and anything behind a login are all invisible. If your feature needs a customer’s private ATS state, no public-data API will get you there. ## The test that resolves it in one question Ask: **does the data belong to a specific customer who has to connect an account, or is it published to the open web?** - **“Show this user their own hiring pipeline”** - customer-credential. No amount of public data reconstructs a private pipeline. - **“Show which companies opened DevOps roles this month”** - public-data. No number of OAuth connections adds up to a market. - **Both** - and this is common in mature products. A sourcing tool reads the customer’s ATS to know who they already rejected, and reads public postings to know who else is hiring that profile. These are two integrations, not one. ## What normalization actually costs The pitch for both kinds is the same: one schema instead of many. The work hidden behind that promise is different in each case, and it is worth knowing which problem your vendor is absorbing. **Customer-credential platforms** absorb auth. OAuth flows, token refresh, per-tenant credentials, wildly different permission models, and vendors that rate-limit per customer. The hard part is that every new customer is a new integration instance that can break on its own. **Public-data platforms** absorb collection. Discovery, fetching, blocking, rendering, extraction, deduplicating the same role posted in five places, and rechecking whether each posting is still open. The hard part is that it never stops - the corpus decays continuously, so the cost is ongoing rather than per-customer. We went through that math in [build vs buy](/blog/job-scraper-build-vs-buy), and the collection mechanisms specifically in [job aggregator sites](/blog/job-aggregator-sites). ## Questions worth asking either kind 1. **What happens when a source changes?** Both categories exist to insulate you from that. Ask how quickly a vendor schema change propagates and whether it is a breaking change for you. 2. **How is the normalized schema versioned?** A unified API that silently reshapes a field is worse than no abstraction, because you stopped watching for it. 3. **What is lost in normalization?** Every mapping drops detail. Ask whether the raw source record is still reachable when you need something the schema does not carry. 4. **How do you know a record is still true?** For a customer-credential API this is sync frequency. For a public-data API it is the recheck loop, which is what separates a live feed from an archive - see [expired job postings](/blog/find-expired-job-postings). ## The honest summary If your feature is about your customer, you want a customer-credential unified API and you should evaluate Merge, Nango, Apideck and Paragon on auth handling and integration breadth. If your feature is about the market, none of those will help you, and you want a public-data API with a real collection and recheck pipeline behind it. Confusing the two is the most expensive mistake in this category, and it is usually made in week one and discovered in week six. For the job-data half: ``` curl https://api.jobspipe.dev/v1/jobs/search \ -H "Authorization: Bearer jp_live_your_key_here" \ -H "Content-Type: application/json" \ -d '{ "job_title_or": ["devops engineer"], "posted_at_max_age_days": 30 }' ``` One schema across job sources, deduplicated and verified open - free tier included. ## Frequently asked questions ### What is a unified API? A unified API normalizes many underlying providers into one schema so you write one integration instead of many. The category splits in two. Customer-credential platforms read data out of your customer's systems after they connect an account. Public-data platforms normalize information that is already published and needs no authorization. They solve different problems and are frequently confused. ### Is Merge a good fit for job posting data? No, because it solves a different problem. Merge and similar customer-credential platforms read a specific customer's ATS after that customer connects their account, which is right for showing a user their own hiring pipeline. They cannot answer which companies are hiring a given role, because you have no relationship with those companies and they have not authorized access. Market questions need a public-data API. ### How do I choose between the two kinds of unified API? Ask whether the data belongs to a specific customer who must connect an account, or is published to the open web. Customer questions like showing a user their own pipeline need a customer-credential platform. Market questions like which companies opened DevOps roles this month need a public-data platform. Mature products often need both, which is two integrations rather than one. [ Next → Job aggregator sites: where each one actually gets its listings ](/blog/job-aggregator-sites) --- Canonical URL: https://jobspipe.dev/blog/unified-api-job-data Title: Unified API platforms: the two kinds, and which one job data needs Description: The unified API category contains two products that get confused constantly - one reads your customer's systems with their credentials, the other reads public data nobody has to authorize. They solve different problems, fail in different ways, and only one of them can answer 'who is hiring right now'. Which platforms sit where, and how to tell which you actually need.