Issue Station
Sign In
Tools hereToolbox

hermes - โœ…(Solved) Fix [Feature]: Support custom domain and encrypted webhook payloads for private Feishu deployments [1 pull requests]

Official PRs (โ€ฆ)
ON THIS PAGE

Recommended Tools

ร—6

Utilities matched from this issueโ€™s tags and category โ€” try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful ยท Quick feedback

Loadingโ€ฆ

Error Message

  1. Encrypted webhook payloads are rejected with a 400 error. Many private Feishu deployments enforce payload encryption via encryptKey, but

Root Cause

Private/self-hosted Feishu deployments (e.g., enterprise deployments on custom domains) are not supported because:

Fix Action

Fixed

PR fix notes

PR #13249: feat(feishu): support custom domain and encrypted webhook payloads

Description (problem / solution / changelog)

  • Allow FEISHU_DOMAIN to accept full URLs for private Feishu deployments
  • Add AES decryption support for encrypted webhook payloads using lark_oapi.AESCipher
  • Preserve domain case sensitivity to support custom URLs
  • Add _resolve_domain() method to handle both standard domains (feishu/lark) and custom URLs

This enables Hermes to work with private/self-hosted Feishu instances that use custom domains and encrypted webhook payloads.

Tested with iFlytek's private Feishu deployment (open.xfchat.iflytek.com).

What does this PR do?

<!-- Describe the change clearly. What problem does it solve? Why is this approach the right one? -->

Related Issue

<!-- Link the issue this PR addresses. If no issue exists, consider creating one first. -->

Fixes #13254

Type of Change

<!-- Check the one that applies. -->
  • ๐Ÿ› Bug fix (non-breaking change that fixes an issue)
  • โœจ New feature (non-breaking change that adds functionality)
  • ๐Ÿ”’ Security fix
  • ๐Ÿ“ Documentation update
  • โœ… Tests (adding or improving test coverage)
  • โ™ป๏ธ Refactor (no behavior change)
  • ๐ŸŽฏ New skill (bundled or hub)

Changes Made

<!-- List the specific changes. Include file paths for code changes. -->

How to Test

<!-- Steps to verify this change works. For bugs: reproduction steps + proof that the fix works. -->

Checklist

<!-- Complete these before requesting review. -->

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: <!-- e.g. Ubuntu 24.04, macOS 15.2, Windows 11 -->

Documentation & Housekeeping

<!-- Check all that apply. It's OK to check "N/A" if a category doesn't apply to your change. -->
  • I've updated relevant documentation (README, docs/, docstrings) โ€” or N/A
  • I've updated cli-config.yaml.example if I added/changed config keys โ€” or N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows โ€” or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide โ€” or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior โ€” or N/A

For New Skills

<!-- Only fill this out if you're adding a skill. Delete this section otherwise. -->
  • This skill is broadly useful to most users (if bundled) โ€” see Contributing Guide
  • SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
  • No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
  • I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

<!-- If applicable, add screenshots or log output showing the fix/feature in action. -->

Changed files

  • gateway/platforms/feishu.py (modified, +26/-14)

Code Example

# Private Feishu deployment                                                                                                                       
  FEISHU_DOMAIN=https://open.xfchat.iflytek.com                   
  FEISHU_CONNECTION_MODE=webhook                                                                                                                    
  FEISHU_ENCRYPT_KEY=your_encrypt_key    

Environment                                                                                                                                       
                                                                                                                                                    
  - Platform: Private/self-hosted Feishu (tested with iFlytek deployment)                                                                           
  - Connection mode: webhook                                                                                                                        
  - lark-oapi: 1.5.4    

### Alternatives Considered

_No response_

### Feature Type

New tool

### Scope

None

### Contribution

- [ ] I'd like to implement this myself and submit a PR

### Debug Report (optional)
RAW_BUFFERClick to expand / collapse

Problem or Use Case

Problem

Private/self-hosted Feishu deployments (e.g., enterprise deployments on custom domains) are not supported because:

  1. FEISHU_DOMAIN only accepts feishu or lark as values, mapped to hardcoded SDK constants. Custom domains like https://open.example.com
    are not supported.

  2. Encrypted webhook payloads are rejected with a 400 error. Many private Feishu deployments enforce payload encryption via encryptKey, but
    Hermes has no decryption logic.

Expected Behavior

  • FEISHU_DOMAIN should accept full URLs for private deployments
  • Encrypted webhook payloads should be transparently decrypted using the configured FEISHU_ENCRYPT_KEY

Proposed Solution

  1. Custom domain: Check if FEISHU_DOMAIN starts with http and pass it directly to the lark SDK's .domain() call (which already accepts
    URL strings)

  2. Encrypted payloads: Use lark_oapi.AESCipher to decrypt the encrypt field before processing the payload

Configuration Example

# Private Feishu deployment                                                                                                                       
FEISHU_DOMAIN=https://open.xfchat.iflytek.com                   
FEISHU_CONNECTION_MODE=webhook                                                                                                                    
FEISHU_ENCRYPT_KEY=your_encrypt_key    

Environment                                                                                                                                       
                                                                                                                                                  
- Platform: Private/self-hosted Feishu (tested with iFlytek deployment)                                                                           
- Connection mode: webhook                                                                                                                        
- lark-oapi: 1.5.4    

### Alternatives Considered

_No response_

### Feature Type

New tool

### Scope

None

### Contribution

- [ ] I'd like to implement this myself and submit a PR

### Debug Report (optional)

```shell

extent analysis

TL;DR

To support private/self-hosted Feishu deployments, modify the FEISHU_DOMAIN validation to accept full URLs and add decryption logic for encrypted webhook payloads using the lark_oapi.AESCipher class.

Guidance

  • Update the FEISHU_DOMAIN validation to check if the value starts with http and pass it directly to the lark SDK's .domain() call.
  • Use the lark_oapi.AESCipher class to decrypt the encrypt field in encrypted webhook payloads before processing.
  • Ensure the FEISHU_ENCRYPT_KEY is properly configured to enable decryption.
  • Test the changes with a private Feishu deployment, such as the iFlytek deployment, to verify the fix.

Example

import lark_oapi

# Assuming FEISHU_DOMAIN and FEISHU_ENCRYPT_KEY are configured
if FEISHU_DOMAIN.startswith('http'):
    # Pass the full URL to the lark SDK's .domain() call
    lark_sdk.domain(FEISHU_DOMAIN)

# Decrypt encrypted webhook payloads
cipher = lark_oapi.AESCipher(FEISHU_ENCRYPT_KEY)
encrypted_payload = request.json['encrypt']
decrypted_payload = cipher.decrypt(encrypted_payload)

Notes

The proposed solution assumes that the lark_oapi library version 1.5.4 is being used, which may not be the case in all environments. Additionally, the FEISHU_ENCRYPT_KEY configuration is required for decryption to work.

Recommendation

Apply the proposed workaround by modifying the FEISHU_DOMAIN validation and adding decryption logic for encrypted webhook payloads. This will enable support for private/self-hosted Feishu deployments.

Vote matrix ยท Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loadingโ€ฆ
#api#API routing#API middleware#SSR setup#ISR setup

Still need to ship something?

ร—6

Another batch ranked right after the header list โ€” different links, same matching logic.

Back to top recommendations

TRENDING

hermes - โœ…(Solved) Fix [Feature]: Support custom domain and encrypted webhook payloads for private Feishu deployments [1 pull requests]