\n\n```\n\n**Or use proper bundler config**:\n```javascript\n// webpack.config.js\nmodule.exports = {\n resolve: {\n fallback: {\n \"fs\": false,\n \"path\": false\n }\n }\n};\n```" } }, { "@type": "Question", "name": "Mock server returns wrong status codes for examples", "acceptedAnswer": { "@type": "Answer", "text": "When you have multiple examples, Prism picks randomly or based on accept headers in ways that don't match your expectations.\n\n**Force specific examples**:\n```bash\nprism mock --dynamic=false your-spec.yaml\n```\n\n**Or use prefer headers**:\n```bash\ncurl -H \"Prefer: example=success\" ${MOCK_SERVER_URL:-http://localhost:4010}/users # Your local mock server\n```\n\n**Debug which example is being used**:\n```bash\nprism mock --verbose your-spec.yaml\n# Look for \"Using example: xyz\" in the output\n```" } }, { "@type": "Question", "name": "Spectral linting false positives with $ref resolution", "acceptedAnswer": { "@type": "Answer", "text": "Spectral sometimes can't resolve external references and throws validation errors for valid specs.\n\n**Common false positive**:\n```\npath-params Operation must define parameter \"{id}\" as expected by path \"/users/{id}\"\n```\n\n**Fix**: Use `--resolve-external-refs` flag:\n```bash\nspectral lint --resolve-external-refs your-spec.yaml\n```\n\n**Or disable the problematic rule**:\n```yaml\n# .spectral.yaml\nrules:\n path-params: false\n```" } } ] }

Common Breakages That'll Ruin Your Day

Q

Stoplight Studio just shows a blank white screen on startup. What the hell?

A

Classic issue especially on Windows with WSL2 or when your display driver is being a dick. The electron app loads but renders nothing.

Q

Studio keeps crashing when I try to save large OpenAPI specs

A

Memory leaks in the electron app, especially with specs over 5MB or deeply nested schemas. Known issue since v2.9.0 that SmartBear hasn't bothered fixing.

Q

"Your files have duplicate stable IDs" error when publishing docs

A

This bullshit error means Stoplight's internal ID system got confused, probably because you copied and pasted sections or renamed files without updating references.

Q

Mock server returns 404 for endpoints that definitely exist

A

Usually happens when your servers configuration is wrong or there's a proxy fuckup.

Q

Authentication headers not working in mock responses

A

Mock servers don't actually validate auth

  • they just return whatever response you defined. But the headers might not be getting passed through properly.

Git Integration Nightmares (And How to Survive Them)

Git integration with Stoplight is like performing surgery with a chainsaw - it works until it doesn't, and when it fails, it takes your afternoon with it.

The YAML Merge Conflict Hell

OpenAPI specs in YAML format turn into unreadable garbage during merge conflicts. Three developers editing the same spec file simultaneously? Prepare for 90 minutes of diff hell.

The Problem: Git's default merge algorithm doesn't understand YAML structure. A simple indentation change makes every line look different:

<<<<<<< HEAD
  responses:
    '200':
      description: Success
      content:
        application/json:
          schema:
=======
  responses:
      '200':
        description: Success
        content:
          application/json:
            schema:
>>>>>>> feature-branch

Best Fix: Use semantic merge tools that understand YAML structure. yq can help resolve conflicts programmatically, and the official YAML specification provides detailed formatting rules for conflict resolution. The Git merge documentation covers advanced merge strategies for complex files:

## Install yq first
brew install yq  # macOS
sudo apt-get install yq  # Ubuntu

## Merge YAML files with conflict resolution
yq eval-all 'select(fileIndex == 0) * select(fileIndex == 1)' base.yaml branch.yaml

Prevention Strategy: Use .gitattributes to define custom merge drivers for YAML files. The Git attributes documentation explains merge driver configuration, while Stack Overflow YAML merge discussions provide community solutions for common conflicts:

*.yaml merge=ours
*.yml merge=ours

Team Workflow: Assign spec file ownership. Only one person edits the main OpenAPI file at a time. Everyone else works on separate files and uses $ref to include their changes. The OpenAPI specification documentation covers $ref usage patterns, and JSON Schema external references explain the underlying reference resolution mechanism. Swagger documentation provides practical examples for splitting large specs.

Branch Syncing Issues with Platform

Stoplight's Git sync frequently gets confused by force pushes, branch renames, or when someone rebases without telling anyone.

Symptoms:

  • "Your branch is behind" when it's not
  • Changes not appearing in platform after push
  • Random 404s on docs that worked yesterday

Debug Process:

  1. Check status.stoplight.io first - platform downtime is more common than they admit
  2. Verify webhook delivery in your Git provider (GitHub/GitLab/etc)
  3. Force a manual sync from Stoplight platform settings

Nuclear Reset: Disconnect and reconnect the Git integration:

  1. Project Settings → Git Integration
  2. Disconnect repository
  3. Wait 5 minutes (seriously, their cache is slow)
  4. Reconnect with same repository URL
  5. Re-configure branch settings

This loses some project history but fixes 90% of sync issues.

File Path Problems

Stoplight gets confused by repository structures it doesn't expect. If your OpenAPI files aren't in the root directory, prepare for random failures.

Works Fine:

project/
├── api.yaml
└── models/
    ├── user.yaml
    └── product.yaml

Breaks Randomly:

project/
├── docs/
│   └── api/
│       └── openapi.yaml
└── src/
    └── models/

Fix: Use explicit file paths in your Stoplight project configuration. Don't rely on auto-discovery.

Relative Path Hell: When using $ref, paths break if you move files around:

## This breaks when you reorganize directories
$ref: '../models/user.yaml#/User'

## This is more resilient
$ref: '#/components/schemas/User'

The "Permission Denied" Mystery

Random authentication failures when Stoplight tries to access your repository, especially with enterprise GitHub/GitLab instances.

Common Causes:

  • OAuth token expired (GitHub tokens expire after 1 year)
  • Repository permissions changed
  • Organization SSO requirements updated
  • SmartBear's IP addresses got blocked by your corporate firewall

Fix Process:

  1. Regenerate Git integration token in your Git provider
  2. Update token in Stoplight project settings
  3. Test with a simple commit to verify access
  4. If still failing, check your network team blocked *.stoplight.io domains

Enterprise Gotcha: If your company uses SAML/SSO, the service account used by Stoplight might need special permissions or exemptions. The GitHub Enterprise SSO documentation covers common integration issues, while Azure AD OAuth troubleshooting helps resolve authentication failures with enterprise identity providers.

Performance Issues with Large Repositories

Stoplight chokes on repositories with thousands of files or deep Git history. Symptoms include slow syncing, timeout errors, and random build failures.

Temporary Fix: Use shallow clones by creating a dedicated documentation repository instead of mixing docs with code:

## Create a docs-only repo
git clone --depth 1 https://github.com/stoplightio/elements.git

Better Solution: Use Git submodules to keep docs separate:

git submodule add https://github.com/stoplightio/spectral.git docs/api

This keeps your main repository clean and Stoplight happy, but adds complexity to your workflow.

Git Workflow Diagram

Docker Integration Architecture

Advanced Breakages and Cryptic Error Messages

Q

"Invalid ruleset provided" when using Spectral CLI

A

This usually happens when your .spectral.yaml config file is malformed or references rules that don't exist.

Check your ruleset syntax first:

## .spectral.yaml
extends: ["spectral:oas"]  # Not "spectral:openapi" 
rules:
  info-contact: true
  info-description: true

Common mistake: Trying to use custom rules that aren't properly defined:

## This breaks
rules:
  my-custom-rule: true  # Rule doesn't exist

## Fix: Define the rule first
rules:
  my-custom-rule:
    description: "Custom validation"
    given: "$.info"
    severity: error
    then:
      field: "contact"
      function: "truthy"

Debug with verbose output:

spectral lint --verbose your-spec.yaml
Q

Prism mock server "Cannot find module" errors in Docker

A

Usually happens when you're trying to use custom functions or rulesets that aren't available in the container.

Standard fix:

FROM stoplight/prism:4
COPY package.json .
COPY node_modules ./node_modules
COPY your-spec.yaml .
EXPOSE 4010
CMD ["mock", "-h", "0.0.0.0", "your-spec.yaml"]

If you don't need custom functions, use the slim image:

docker run --init --rm -p 4010:4010 stoplight/prism:4 mock -h 0.0.0.0 your-spec.yaml
Q

"SSL Error: SELF_SIGNED_CERT_IN_CHAIN" with corporate networks

A

Corporate firewalls and proxy servers fuck up SSL certificate validation for Stoplight's API calls.

Quick fix for development:

## Disable SSL verification (NOT for production)
export NODE_TLS_REJECT_UNAUTHORIZED=0

Proper fix: Add your corporate CA certificates:

## Find your corporate CA cert
openssl s_client -showcerts -connect api.stoplight.io:443

## Add to system certificate store
sudo cp corporate-ca.crt /etc/ssl/certs/
sudo update-ca-certificates
Q

"Error when using multipart/form-data" in mock responses

A

Prism's multipart handling is limited compared to real servers. You can define the schema but don't expect complex file upload mocking.

What works:

requestBody:
  content:
    multipart/form-data:
      schema:
        type: object
        properties:
          file:
            type: string
            format: binary
          metadata:
            type: string

What doesn't work: Dynamic file processing, multiple file uploads, complex form validation.

Workaround: Use examples with static responses:

responses:
  '200':
    description: File uploaded successfully
    content:
      application/json:
        example:
          fileId: "12345"
          status: "uploaded"
Q

"Module not found: Error: Can't resolve 'fs'" when using Elements

A

This happens when trying to use Stoplight Elements in a browser environment - it's trying to access Node.js filesystem APIs that don't exist in browsers.

Fix: Use the CDN version instead of npm package:

<script src="https://unpkg.com/@stoplight/elements/web-components.min.js"></script>
<elements-api apiDescriptionUrl="./your-spec.yaml"></elements-api>

Or use proper bundler config:

// webpack.config.js
module.exports = {
  resolve: {
    fallback: {
      "fs": false,
      "path": false
    }
  }
};
Q

Mock server returns wrong status codes for examples

A

When you have multiple examples, Prism picks randomly or based on accept headers in ways that don't match your expectations.

Force specific examples:

prism mock --dynamic=false your-spec.yaml

Or use prefer headers:

curl -H "Prefer: example=success" ${MOCK_SERVER_URL:-http://localhost:4010}/users  # Your local mock server

Debug which example is being used:

prism mock --verbose your-spec.yaml
## Look for "Using example: xyz" in the output
Q

Spectral linting false positives with $ref resolution

A

Spectral sometimes can't resolve external references and throws validation errors for valid specs.

Common false positive:

path-params Operation must define parameter "{id}" as expected by path "/users/{id}"

Fix: Use --resolve-external-refs flag:

spectral lint --resolve-external-refs your-spec.yaml

Or disable the problematic rule:

## .spectral.yaml
rules:
  path-params: false

Platform Failures and Performance Issues

The hosted Stoplight platform works great until it doesn't. When it breaks, it usually takes half your team's productivity with it.

Documentation Publishing Failures

"Publishing" your documentation is where things frequently go sideways. The process involves multiple steps - syncing from Git, validating specs, generating docs, and deploying to CDN. Any step can fail silently.

Most Common Failure: Duplicate stable IDs. This happens when Stoplight's internal content management system gets confused about which pieces of content belong where.

The error message is useless: Your files have duplicate stable IDs. You must re-assign stable IDs before publishing.

Real fix: The stable IDs are stored in hidden metadata that's not visible in the UI. You need to:

  1. Export your project data (if possible)
  2. Delete the problematic files from Stoplight platform
  3. Clear browser cache and cookies for *.stoplight.io
  4. Re-upload/sync files from scratch
  5. Reconfigure any custom domains or publication settings

This takes 30 minutes if you know what you're doing, 3 hours if you're figuring it out.

Prevention: Never copy entire project structures between Stoplight workspaces. Always create new projects from scratch and migrate content file by file. The Stoplight project management documentation covers proper project setup workflows, while OpenAPI migration best practices provide guidance for moving content between tools.

Mock Server Memory Issues

Prism mock servers eat RAM like a hungry teenager, especially when handling large specs or high request volumes. Default container limits are too low for production-like testing.

Symptoms:

  • Responses getting slower over time
  • Random connection errors
  • Container getting killed by OOMKiller (Linux OOMKiller documentation)
  • Mock responses returning null unexpectedly

These issues are well-documented in Docker memory troubleshooting guides and Node.js memory management best practices.

Container Resource Fix:

FROM stoplight/prism:4
## Increase Node.js heap size  
ENV NODE_OPTIONS=\"--max-old-space-size=2048\"
COPY your-spec.yaml .
EXPOSE 4010
CMD [\"mock\", \"-h\", \"0.0.0.0\", \"your-spec.yaml\"]

Docker Compose:

services:
  mock-server:
    image: stoplight/prism:4
    command: mock -h 0.0.0.0 /app/spec.yaml
    mem_limit: 1g
    mem_reservation: 512m
    environment:
      - NODE_OPTIONS=--max-old-space-size=1024

Memory Leak Workaround: Restart mock servers every few hours in CI/CD:

## Add to your test script
docker restart prism-mock-server
sleep 10

Docker Container Memory Management

API Monitoring Workflow

Platform Sync Failures

Git integration breaks more often than Stoplight admits. Their webhook system is fragile and doesn't handle edge cases well.

Silent Failures: The most dangerous type. Platform shows "Last synced: 2 hours ago" but your latest commits aren't reflected in docs. Users see outdated information and blame your API for being wrong. The Stoplight community forums frequently discuss sync issues, while API documentation best practices recommend automation strategies to prevent these problems.

Detection: Set up monitoring to compare Git commits with published doc timestamps using GitHub webhooks or GitLab webhooks. The Stoplight API documentation provides endpoints for programmatic status checking, and monitoring tools like Uptime Robot can track documentation availability:

#!/bin/bash
## Check if docs are current
LAST_COMMIT=$(git log -1 --format=\"%ct\")
LAST_SYNC=$(curl -s https://status.stoplight.io/api/v2/status.json | jq -r '.page.updated_at')

if [ $LAST_COMMIT -gt $LAST_SYNC ]; then
    echo \"WARNING: Docs are stale\"
    # Send alert to Slack/email/whatever
fi

Manual Sync Trigger: When automatic sync fails, you can force it through the platform UI, but there's a rate limit. Too many manual syncs will temporarily block your project.

Component Library Beta Disasters

Stoplight's "component libraries" feature has been in beta for over 2 years and regularly breaks in spectacular ways.

What it's supposed to do: Share reusable schemas and components across projects in your organization.

What actually happens:

  • Components randomly become unavailable
  • References break when someone renames a component
  • Circular dependencies crash the UI
  • Version conflicts between projects using the same components

Survival Strategy: Don't rely on component libraries for production documentation. They're too unstable. Instead:

  1. Use Git submodules for shared schemas
  2. Copy-paste components between projects (easier to maintain)
  3. Keep a local backup of any "shared" components
  4. Test component library changes in a staging environment first

Enterprise SSO Authentication Loops

SmartBear's enterprise authentication integration is a masterclass in how not to implement SSO. Common issues include infinite redirect loops, session timeouts, and permissions that randomly reset.

Redirect Loop Fix:

  1. Clear all cookies for *.stoplight.io and *.smartbear.com
  2. Clear browser cache
  3. Try incognito/private browsing first
  4. If still failing, check your IdP logs for error details

Permission Reset Problem: Enterprise admin permissions periodically reset to default values. Keep a record of who has what access and check it monthly.

Session Timeout Issues: Enterprise sessions expire much faster than expected (sometimes 1 hour instead of 8). Configure your IdP for longer session times or accept that users will need to re-auth frequently.

Documentation Build Timeouts

Large API specifications (>10MB) or projects with hundreds of endpoints can timeout during the build process. The error messages don't explain this - you just get "build failed" with no details.

Size Limits (undocumented):

  • Individual files: ~5MB
  • Total project size: ~50MB
  • Number of endpoints: ~500 paths
  • Schema complexity: ~10 levels deep

Workaround: Split large specs into multiple smaller specifications:

## Split by API version
api-v1.yaml
api-v2.yaml

## Or by feature area  
users-api.yaml
payments-api.yaml
notifications-api.yaml

Each gets its own Stoplight project and published documentation URL.

Performance Optimization: Remove unused schemas and examples. Every component defined in your OpenAPI spec gets processed during builds, even if it's not referenced anywhere.

Build Monitoring: Stoplight doesn't provide build logs or timing information. You're flying blind when builds fail. Keep your own logs of successful builds and their timing to identify when performance degrades.

Essential Troubleshooting Resources