[Fix] Issue-1094 Redirect /api/logo to signed CloudFront URL

[foreverabhi2002]

Description

Closes #1094

Updated the /api/logo endpoint to redirect successful logo requests directly to the generated signed CloudFront url instead of returning the url inside a JSON response.

This allows the API endpoint to be used directly as an image source in HTML, Markdown, email templates, and other clients that expect an image resource.

The existing authentication, validation, rate limiting, logo lookup, and error handling behavior remains unchanged.

What type of PR is this? (Check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📄 Documentation Update
• 👨‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🛠️ CI/CD

Screenshots (if applicable)

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openlogo-prod-web	Ready	Preview	Aug 23, 2026 2:40pm
openlogo-staging-web	Ready	Preview	Aug 23, 2026 2:40pm

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[devin-ai-integration]

Code review

The change itself is small and correct for the stated goal, but it is a breaking public-API change and a few things around it are unhandled.

1. Documentation still describes the old JSON contract

packages/ui/src/utils/Constants.js is now wrong in three places:

• CODE_EXAMPLE (JS/Python samples) do await response.json() / response.json() — with a 302 fetch transparently follows to CloudFront and the body is image bytes, so .json() now throws for every existing integration.
• HERO_SECTION.code.response.body advertises { url: ..., format: "svg" }.
• DOCUMENTATION.apiDocs["Logo Retrieval"] doesn't mention that the endpoint redirects.

Please update these in this PR, and consider whether existing consumers need an opt-out (e.g. Accept: application/json or ?format=json keeps the old envelope). Right now integrations break silently with no version gate.

2. Redirect is cacheable but the target expires in 5 minutes

cloudFrontSignedURL signs with dateLessThan: Date.now() + 5 min (packages/app/utils/cloudFront.js:16). A bare res.redirect(302, url) can be cached by browsers/proxies/CDNs in front of the API, after which clients follow an expired signature and get a CloudFront 403 instead of an image. Set Cache-Control: no-store (or a max-age shorter than the signature TTL) on the redirect response.

3. The redirect target isn't always your CDN

fetchImageByCompanyFree falls back to grabCompanyLogos(...) and returns scrapedResults.logos[0].url — an arbitrary third-party URL derived from scraping. Previously that URL was inert JSON data; now your authenticated endpoint 302s clients to an externally-controlled host. Worth restricting the redirect to the CloudFront domain (and proxying/streaming or still returning JSON for scraped results), otherwise this is effectively an attacker-influenceable redirect.

4. Cross-origin consumers

Browser JS calling /api/logo will follow the redirect to CloudFront, which must return CORS headers for the request to succeed; <img src>/Markdown usage (the motivation for this PR) is unaffected. Please verify the CDN's CORS/response headers, since silently breaking fetch consumers is the main risk here.

5. Mixed response shapes

Success is now a redirect while every error path still returns the {statusCode, message, error} envelope. That's fine, but it should be stated in the docs, and clients that auto-follow redirects can no longer distinguish "logo found" from a CDN error without inspecting the final status.

Tests

Asserting response.headers.location is the right check. Please also add:

• a test that a non-2xx path still returns JSON (guards against future "everything redirects" refactors),
• a test for the scraped-URL branch (currently untested and now security-relevant),
• an assertion for whatever caching header you add in (2).

Nothing blocking in the implementation itself — items 1–3 are what I'd want fixed before merge.

Written by Devin