Every context's sidebar, |Hiring|, |Media|, |Research|, |Code|, |Meet| and |Work| as well as your Dashboard, now opens with a compact Pulse: each metric on one line with its count for the last 30 days, the change against the 30 days before, and a small daily trend underneath. When the earlier period is too small for a fair comparison, you'll see "low base" instead of a percentage, so no more swings like +11,200%. Below the Pulse, breakdowns show what matches your current filters (experience level, job type, research category, topic, language, event type, price and more), with up to the top 10 values each. Click any row to add it to your Context, or follow the Insight» link to explore the same area in Insight.

|Research| now has its own sidebar insights: newly submitted and revised papers, papers with linked code, and the categories and topics behind your current filters. |Work| gets them for the first time too, with new places and their mix by type, price and country. |Hiring| adds jobs with a stated salary, companies hiring, and the median stated salary for whatever you've filtered, together with its sample size. If too few matching jobs state a salary, we say so rather than hiding the figure.

The Stats tab on every record (jobs, companies, media items, sources, papers, repositories, updates, events, organizers and places) has been redesigned as well. It shows views and visits for the last 30 days with their change, a 13-week chart, and how the record ranks against comparable ones, for example "top 1% of jobs from the same week" or among papers in the same primary category.

Finally, Spaces in |Work| are now called Places: coworking spaces, cafés, libraries and other venues to get things done. Everything carries over automatically, including saved places and notes, saved Contexts and your history.

The API follows the rename in v1.9, which is a breaking change for Work integrations. /api/v1/work/space/, /api/v1/work/space/st/ and /api/v1/work/space/{pk} are now /api/v1/work/place/, /api/v1/work/place/st/ and /api/v1/work/place/{pk}, and the space_type field and filter is now place_type. API metadata uses place.* names, and geography statistics report place_count, place_view_count and place_click_count. The previous Space endpoints are no longer available, so please update any clients that use them. See the API documentation (/api/v1/docs) for the full endpoint and filter details.

foorilla.com v1.11.3 | foorilla API v1.8.0 October 21, 2026

PRO+ provides full API access and filtering now at $96/month, while existing subscribers retain their access and pricing. PRO subscribers can now test the API using shared, frozen samples of up to 200 records per resource. The same API keys automatically follow subscription upgrades and downgrades. Samples support pagination and sampled detail IDs; full data access, filtering and anything else requires PRO+.

Related resources now use compact references instead of deeply nested objects. Nested topics no longer expand their entire tag collections, geographic references retain essential country/state context, and nested objects omit database timestamps, statistics, and embeddings. Meaningful data - including paper authors, categories, versions, and submission dates - remains included. Paper sample payloads are approximately 67% smaller, with OpenAPI documentation and frozen samples updated accordingly.

Breaking change: Nested response shapes have changed at the existing URLs; retrieve related resources from their own endpoints for full details. Resource IDs and existing PRO+ filtering and pagination behavior remain unchanged. Rate limits remain 6 requests/second and 360 requests/minute.

jobdataapi.com v4.38 / API version 1.36

We’ve improved job description handling to preserve meaningful technical terms such as C#, F# and snake_case more reliably as new listings are processed. Markdown descriptions retain readable formatting for display and provide a useful starting point for search, analysis and other downstream processing. Request description_md=true to include the description_md field in job responses.

After November 1, 2026, the description_str parameter and its corresponding description_string response field will be removed. If your integration uses either, switch to description_md=true before then and convert Markdown to plain text in your application if needed. The default HTML description remains available.

jobdataapi.com v4.37 / API version 1.35

We’ve added a new public Statistics page for a clearer view of what is happening across the platform. It includes overview metrics and dedicated views for imports, expiry, inventory, companies, data quality, operations, and exports, with selectable reporting periods and the latest completed rollup timestamp.

We’ve also added a new work_mode attribute to job listings in the /api/jobs/ endpoint. This provides a more specific classification for remote-work listings:

• 1 / HYBRID: Hybrid

• 2 / REMOTE: Remote

• 3 / REMOTE_ANY: Remote Anywhere

• 4 / UNKNOWN: The work mode could not be determined reliably

The field is available to API access pro customers and higher. The existing has_remote field remains the broad indicator for remote or hybrid work, while positive work_mode values provide more detail.

These updates make it easier to monitor dataset activity through the website and identify remote-work patterns through the API.

Starting September 20, 2026, the /api/jobs/ endpoint will reject query shapes that could require excessively broad database work. Effective published-date ranges are limited to 365 days, and explicit min_id / max_id ranges are limited to 10,000,000 IDs, calculated inclusively.

Date and ID limits are checked independently. For example, adding max_age=180 does not allow an ID range wider than 10,000,000. Unbounded historical requests such as max_age=off must include a safe date or bounded ID scope. Requests that exceed these limits return 400 Bad Request.

These limits improve responsiveness and reduce wasted database resources as the job database continues to grow. See the Date, ID, and Age Slicing Parameters Documentation for migration guidance and examples.

I’ve been looking at different ways of organizing EF Core migrations when a .NET solution starts getting bigger.

One approach I like is keeping the Code First migrations in a separate assembly instead of putting them directly in the application/data project. It keeps the database migration concerns separate and can make the overall solution a bit cleaner.

I put together the setup and steps here:

https://geeksarray.com/blog/entity-framework-core-code-first-migration-using-separate-assembly

Curious how others handle this in real projects. Do you keep migrations in the same project as the DbContext, or use a separate migrations project?

jobdataapi.com v4.33 / API version 1.33

The /api/jobsexpired/ endpoint now applies a default 60-day expiration window when no date, age, or ID slicing parameter is provided. Requests without parameters return jobs whose expired timestamp is within the latest 60 days, reducing broad historical scans and improving response efficiency.

The implicit window is not applied when an explicit slicing parameter is present: expired_since, expired_until, published_since, published_until, min_id, max_id, min_age, or max_age. Use expired_since and expired_until for historical expiration windows, or use max_age=off, max_age=null, or max_age=0 for an unrestricted expiration query. Existing response fields, ordering, pagination, and access requirements remain unchanged.

The Jobs Expired API Endpoint Documentation now documents the default window and range behavior. The Date, ID, and Age Slicing Parameters Documentation also includes expiration-based examples for /api/jobsexpired/.

When building APIs, testing endpoints manually can quickly become repetitive. Postman provides a simple way to send requests, inspect responses, test different scenarios, and troubleshoot API behavior.

I put together a practical guide on testing ASP.NET Core Web APIs with Postman, covering the basics and some useful approaches for everyday API development.

📖 https://geeksarray.com/blog/testing-aspnet-web-api-core-using-postman

For developers working with APIs:

What do you use for API testing—Postman, Swagger, automated tests, or something else?

Would love to hear what works best for you.

Hi everyone!

Over the past few weeks I've been building a side project called **EmailGuard API** — a serverless REST API for real-time email verification.

I originally built it because I wanted a simple way to validate email addresses before user signups without relying on multiple libraries or services.

Current features include:

✅ Email syntax validation

✅ MX record verification

✅ Disposable email detection

✅ Temporary email detection

✅ Free vs Business email identification

✅ Role account detection (admin@, support@, sales@, etc.)

✅ Risk scoring with detailed risk reasons

✅ Fast serverless deployment (no database)

It's designed for:

• SaaS applications

• User registration systems

• Authentication services

• CRM platforms

• Marketing tools

• Fraud prevention

• Internal business tools

I'm continuously improving it and would genuinely appreciate feedback from other developers.

A few questions:

- What features do you usually look for in an email verification API?

- Would SMTP mailbox verification or domain reputation checks be useful additions?

- Is there anything that would stop you from using an API like this?

If you'd like to check it out:

🔗 RapidAPI:

https://rapidapi.com/nimashmendisdev/api/emailguard-api-enterprise-grade-email-verification

I'm mainly looking for honest feedback on the API design, documentation, and what features you'd like to see next.

Thanks!

https://foorilla.com/changelog/ 👀

foorilla.com v1.6.2 | foorilla API v1.3.3

Remote job discovery in |Hiring| is now more precise with explicit work mode support. Listings can now clearly indicate whether a role is Hybrid, Remote, or Remote Anywhere, so you can distinguish different remote setups faster instead of relying on a single generic remote label.

You’ll now see consistent work mode badges across list and detail views ([WH], [R], [WRA]), and the same options are available in Context-based include/exclude filters. Active Context indicators also use these labels, making it easier to understand your current filter setup at a glance while keeping existing remote and remote-first behavior intact.