All feed pages

City feed

DevOps & SRE Jobs API

DevOps and SRE roles from companies building at scale. DevOps and SRE — matched across the titles this discipline actually uses.

The Problem

DevOps and SRE roles are filed under 'Software Engineer' more often than not. A single-title filter misses half the market — you need to match across DevOps and SRE to get focused coverage.

Our Solution

We match across both title variants simultaneously, giving you a focused DevOps and SRE feed without the noise from unrelated infrastructure roles.

What you're getting

Source
Direct postings from ATS and employers career sites.
Companies
This batch includes roles from Deutsche Telekom IT Solutions Slovakia, Sopra Steria, Davies, GSSTech Group, and Opalus Investments LLC, and more.
Volume
Preview shows 10 roles (limit 10, with more pages available). Authenticate and paginate to explore the full DevOps & SRE Jobs index.
Filters
Filter by country, state, city, title, remote setting, experience level, and salary. Full filter reference in the Jobs API docs.

At a glance

  • Multi-title matching across DevOps and SRE — one query, focused coverage.
  • Cloud, Kubernetes, and CI/CD roles well represented — companies using Greenhouse and Lever tend to have mature engineering practices.
  • Normalized salary data where available — ops roles often have significant salary variance that's useful for boards surfacing compensation.

When you are ready for every filter, validation rule, and response field, use the Jobs API reference.

Global Platform Scale

1,577,168

Total Jobs Indexed

+10,320

Added Past 24h

+852,605

Added Past 30 Days

24,882

Employers

Example request

Same query as the playground, as cURL. Use your real key on the server only.

curl -X GET "https://api.cleanjobdata.com/jobs?title=DevOps%3BSRE&max_age=30d" \
  -H "Authorization: Bearer YOUR_API_KEY"

How to integrate

1. Get an API key

Sign up for CleanJobData, open the dashboard, and create or copy your API key. Send it as Authorization: Bearer <token> on every request (server-side only in production—never expose keys in mobile apps or public repos).

2. Query DevOps & SRE Jobs listings

Use the filters already configured for DevOps & SRE Jobs on this page (see the query examples above), then extend the query string with any parameter from the Jobs API reference (/docs/api/jobs) — title, remote, experience_level, salary, and more all combine in the same request.

Use a modest limit while prototyping, default to sort_by=published for recency, then follow pagination.next_page for large imports. Back off with exponential retry if you hit rate limits.

3. Shape data for your product

List responses default to a lightweight field set with no description — add extra_fields=description when a view needs the full HTML body (e.g. GET /jobs?extra_fields=description), or pass fields=id,title,company,location,salary_min,salary_max to replace the default set entirely with just what a card renders. Detail requests (GET /jobs/:id) always include description, no extra param needed.

FAQ

Can I use this in production for a paid job board?

Yes—that is the intended use case. The free Trial tier (250 list + 500 detail requests/mo, no card required) is enough to prototype and verify data quality; Starter ($97/mo, 100,000 requests/mo) and Pro ($297/mo, 500,000 requests/mo) cover most production job boards. Keep your API key server-side, cache responses where it makes sense, and follow the cursor pagination contract for large imports.

How do I narrow results beyond DevOps & SRE Jobs?

Combine the location filters already applied on this page with title (GET /jobs?title=React+engineer), remote=true or the finer remote_type=fully_remote|remote_country|remote_region|hybrid, experience_level=SE,EX for seniority, or salary=100000,180000 for a compensation range. Every combination is documented with validation rules on the Jobs API reference (/docs/api/jobs).

What rate limits or quotas should I expect?

Every response includes X-RateLimit-Limit and X-RateLimit-Remaining headers, so you can watch your usage and slow down before hitting a 429 rather than reacting to one. The per-second limit resets within a second or two if you do hit it — a short wait and retry is enough. A separate, unrelated 429 fires if you exhaust your plan's monthly request quota; that one won't clear by waiting, so check the error message text to tell the two apart.

How is this different from scraping job boards myself?

We normalize employers, locations, salary text, and remote flags into one schema, refresh listings continuously, and expose stable HTTP filters. You spend time on product and UX instead of repairing scrapers every time a site changes markup.

How fresh is the job data?

We refresh listings continuously from our sources. Use sort_by=published (the default) for newest-first ordering, and for incremental syncs use created_max_age=1d (or 6h, 7d — a rolling window on ingestion time) rather than published_after, since a listing can finish processing after its original publish date and published_after alone can miss it.

Do you return full job descriptions on list endpoints?

Not by default — list responses use a lightweight field set to keep list pages and mobile clients fast. Add extra_fields=description to a list request (e.g. GET /jobs?extra_fields=description) to include it, or use fields=id,title,description,... to request an explicit set. The single-job detail endpoint (GET /jobs/:id) always includes the full description with no extra param needed.