feat(api): Hybrid auth for workflows api endpoints

[Lutherwaves]

Summary

• Use hybrid auth for workflows api routes

Implements #1335

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

How has this been tested? What should reviewers focus on?

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

[vercel]

@Lutherwaves is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Overview

Summary

This PR successfully implements hybrid authentication for the workflows list endpoint, enabling programmatic access via API keys while maintaining session-based authentication for the web UI. The implementation replaces getSession() with checkHybridAuth() in both GET and POST handlers, allowing users to authenticate using either cookies, API keys, or internal JWT tokens.

Key changes:

• Updated import from @/lib/auth to @/lib/auth/hybrid
• Modified request parameter type from Request to NextRequest for proper typing
• Replaced session-based user ID extraction with hybrid authentication result handling
• Maintained all existing functionality including workspace validation and error handling

The implementation is clean, follows existing patterns, and directly addresses the feature request in issue #1335.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• Score reflects a straightforward implementation that follows existing patterns, maintains backward compatibility, and includes proper error handling
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/app/api/workflows/route.ts	5/5	Successfully replaced session-only auth with hybrid auth supporting both session and API key authentication

Sequence Diagram

sequenceDiagram
    participant Client
    participant WorkflowAPI as /api/workflows
    participant HybridCheck as checkHybridAuth
    participant SessionSvc as Session Service
    participant HeaderSvc as Header Service
    participant DB as Database

    Client->>WorkflowAPI: Request workflows
    WorkflowAPI->>HybridCheck: Verify identity
    
    alt Session Cookie Present
        HybridCheck->>SessionSvc: Check session
        SessionSvc-->>HybridCheck: Return user ID
    else Request Header Present
        HybridCheck->>HeaderSvc: Validate header
        HeaderSvc-->>HybridCheck: Return user ID
    else No Credentials
        HybridCheck-->>WorkflowAPI: Identity check failed
        WorkflowAPI-->>Client: 401 Unauthorized
    end
    
    HybridCheck-->>WorkflowAPI: Identity verified with user ID
    WorkflowAPI->>DB: Query workflows for user
    DB-->>WorkflowAPI: Return workflows
    WorkflowAPI-->>Client: 200 OK with workflow data

Loading

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[Lutherwaves]

@waleedlatif1 seems the bots have given us their blessing

[icecrasher321]

We should add this into our me/ endpoint set similar to usage-limits --> and it doesn't have to return all fields related to the workflow. Making the internal route externally accessible is not in line with the pattern we want to follow.

[Lutherwaves]

We should add this into our me/ endpoint set similar to usage-limits --> and it doesn't have to return all fields related to the workflow. Making the internal route externally accessible is not in line with the pattern we want to follow.

That is a good point. Let me look into it.

[Lutherwaves]

We should add this into our me/ endpoint set similar to usage-limits --> and it doesn't have to return all fields related to the workflow. Making the internal route externally accessible is not in line with the pattern we want to follow.

I looked at the /me approach you are referring to. It seems if we want to expose workflows listing there we would have to think about what information we want to return for the workflows.

I think having duplicated APIs (external vs internal) isn't the most scalable architecture to have in general. Why not simply expose a single api, then manage what users can see based on their permissions, as opposed to having different internal/external endpoints. Let me know how I can better align with the pattern you want to follow, nonetheless.

[Lutherwaves]

@waleedlatif1 @icecrasher321 were you able to take a look?