For a GitHub Actions-centered workflow, I would separate the problem into four CI stages instead of choosing one platform first:

1. Spec linting / governance

   • Spectral is still a strong baseline for OpenAPI linting.
   • It works as a CLI and in CI, so it is easy to run on every PR.
   • Docs: https://docs.stoplight.io/docs/spectral/9ffa04e052cc1-spectral-cli

2. Mocking

   • Prism is useful when you want a mock server directly from an OpenAPI document.
   • Docs: https://docs.stoplight.io/docs/prism/674b27b261c3c-overview

3. Contract / behavior testing

   • Schemathesis is worth considering if you want generated API tests from OpenAPI schemas.
   • It has a GitHub Action: https://github.com/schemathesis/action

4. Docs publishing

   • Redocly, Scalar, Swagger UI, or another docs renderer can be run from CI and published to Pages, S3, Cloudflare Pages, etc.

A simple Actions workflow can look like this:

name: api-contract

on:
  pull_request:
    paths:
      - "openapi/**"
      - ".github/workflows/api-contract.yml"

jobs:
  lint-openapi:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g @stoplight/spectral-cli
      - run: spectral lint openapi/api.yaml --fail-severity=warn

  contract-test:
    runs-on: ubuntu-latest
    needs: lint-openapi
    steps:
      - uses: actions/checkout@v4
      - uses: schemathesis/action@v3
        with:
          schema: openapi/api.yaml
          base-url: http://localhost:3000

For teams moving away from Stoplight, I usually see two viable patterns:

• Composable open-source stack: Spectral + Prism + Schemathesis + Redocly/Scalar. Best when the API contract lives in Git and PR review is the source of truth.
• Integrated platform: Apidog, Postman, Redocly, or similar. Best when product/design/support teams need a hosted collaboration UI in addition to CI.

The key decision is where the canonical OpenAPI file lives. If Git is the source of truth, then every PR should at least run:

• OpenAPI syntax validation
• Spectral rules / style guide
• breaking-change checks against main
• generated docs preview or artifact
• optional mock/contract tests

That keeps API changes synchronized with the codebase regardless of which UI platform you use. The platform should consume or publish from the Git-tracked OpenAPI file, not become a second source of truth.

Good question — worth noting that Stoplight has been progressively absorbed into SmartBear's API Hub (its parent company), which is likely why a lot of teams are currently migrating away from it.
For GitHub Actions-based workflows specifically, these are the alternatives that come up most often from other teams:

1. Redocly (CLI + platform) — Probably the most direct replacement, since both are purely OpenAPI-based. It includes linting, bundling, and ready-to-use CI checks, with an official GitHub Action (redocly/openapi-github-action) to validate the spec on every PR. Good pick if your priority is keeping validation plus auto-generated docs together.
2. Spectral (originally from Stoplight, but open-source and standalone) — If you only need the OpenAPI linting/validation part in your pipeline (not the full design/mocking package), Spectral is still maintained as an independent tool and has an official GitHub Action. A lot of teams leaving Stoplight Studio just keep Spectral for CI.
3. SwaggerHub — If you're after org-level governance (multiple teams, multiple APIs, shared style rules), it's the most direct competitor to Stoplight's design-first approach, with GitHub Sync pushing to a repo on every save.
4. Apidog (the tool you're already evaluating) — Worth knowing it combines design + mocking + testing + a CLI for CI/CD in one platform, which fits what you describe wanting (fewer standalone tools).

To answer your specific questions:

Migrating away from Stoplight? Yes, that's common right now, mainly due to the SmartBear/API Hub restructuring.
Validating OpenAPI on every PR? The most common pattern is: Spectral or Redocly CLI running as a GitHub Actions step, failing the build if linting catches style violations or breaking changes.
Keeping API changes synced with the codebase? The "spec-as-source-of-truth" approach (define OpenAPI first, generate code/tests from it) best avoids drift — tools like Redocly or SwaggerHub with GitHub Sync help keep that automated.

We’re exploring a similar workflow. Apidog looks interesting for combining API design, testing, and CLI automation, especially when integrating validation into GitHub Actions. Keeping API checks in the same CI workflow as the code makes a lot of sense.