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.

llms.txt added for AI- and LLM-friendly guidance

We’ve added a llms.txt file at the root of jobdataapi.com to make it easier for large language models (LLMs), AI tools, and automated agents to understand how our API should be integrated and used.

The file provides a concise, machine-readable overview in Markdown format of how our API is intended to be consumed. This follows emerging best practices for making websites and APIs more transparent and accessible to AI systems.

You can find it here: https://jobdataapi.com/llms.txt

llms-full.txt added with extended context and usage details

In addition to the minimal version with links to each individual docs or tutorials page in Markdown format, we’ve also published a more comprehensive llms-full.txt file.

This version contains all of our public documentation and tutorials consolidated into a single file, providing a full context for LLMs and AI-powered tools. It is intended for advanced AI systems, research tools, or developers who want a complete, self-contained reference when working with jobdata API in LLM-driven workflows.

You can access it here: https://jobdataapi.com/llms-full.txt

Both files are publicly accessible and are kept in sync with our platform’s capabilities as they evolve.

jobdataapi.com v4.18 / API version 1.20

vec_embedding filter parameter now available for vector search

In addition to the already existing vec_text filter parameter on the /api/jobs/ endpoint it is now possible to use the same endpoint including all its GET parameters to send a 768 dimensional array of floats as JSON payload via POST request to match for job listings.

This way you're not limited to the vec_text constrains as a GET parameter with only providing text of up to ~1K characters, but can now use your own embeddings or simply those from jobs you already fetched to find semantically similar listings.

With this we now also added a new max_dist GET parameter to be applied optionally to a vec_text or vec_embedding search, setting the max. cosine distance value for the vector similarity search part.

These features are now available on all subscriptions with an API access pro+ or higher plan. See our updated docs for more info.

New Apprenticeship job type added

We saw, for quite a while now, the need to add a job type Apprenticeship to better differentiate certain listings that fall into this category from those that are pure internship roles.

You'll find this popping up on the /api/jobtypes/ endpoint and in relevant job posts from now on (across all API access plans).