DingTalk

La integración con DingTalk es solo-notificación hoy (push de alertas disparadas a un grupo de DingTalk). El modo bidireccional IM-bridge está planeado pero no enviado; el validator acepta dingtalk en stream/webhook mode para compatibilidad forward.

Modo	Estado
Notificación	Soportado. Bot custom de grupo, firmado.
IM bridge	Scaffold presente; soporte de producción deferred.

Payload

El bot custom de DingTalk acepta la forma estándar de mensaje de texto:

{
  "msgtype": "text",
  "text": {"content": "[CRITICAL] node-01 swap_high\nswap_in_pages > 1000 for 5m\nsource: alert\ndedupe: alert:swap_high:device=7"}
}

El body en sí no está firmado. DingTalk autentica el request vía parámetros de URL query — ver firma.

Este es el mismo formatter de texto plano que usan los senders de Feishu y WeCom, producido por formatText.

Firma

Cuando el bot custom tiene 加签 (signed) encendido, DingTalk requiere que el request lleve un timestamp y un sign como parámetros de URL query:

timestamp    = milliseconds since epoch
stringToSign = timestamp + "\n" + secret
sign         = base64(HMAC-SHA256(key=secret, message=stringToSign))

La signing key es solo el secret (a diferencia de Feishu, donde el secret es parte del string-to-sign). El helper signDingTalkURL anexa ambos query params:

POST https://oapi.dingtalk.com/robot/send?access_token=…&timestamp=1717012345000&sign=…

El body se queda como JSON plano. La URL firmada más el body es contra lo que DingTalk autentica.

Usa timestamps en milisegundos

La firma de DingTalk espera milisegundos, no segundos. El signer usa time.Now().UnixMilli(). Un timestamp de precisión segundo da una respuesta 310000 "sign invalid".

Setup

1. En el grupo de DingTalk target → 群设置 → 智能群助手 → 添加机器人 → 自定义. Dale un nombre y avatar.
2. Elige 安全设置 → 加签 y copia el secret. (También puedes elegir IP allowlist o filtro de keyword en su lugar; el sender de Ongrid soporta cualquiera, pero se recomienda el modo signed.)
3. Copia la URL del webhook — se ve como https://oapi.dingtalk.com/robot/send?access_token=<token>.
4. En Ongrid: Settings → Channels → New → Provider = dingtalk → Endpoint = la URL del webhook → Secret = el secret de firma del paso 2 (sáltatelo si elegiste el modo keyword o IP allowlist).

El mensaje de prueba debe matchear la regla "safety" del grupo

Si elegiste filtro de keyword, el body del mensaje de prueba DEBE contener esa keyword o DingTalk lo rechaza. El mensaje de prueba default de Ongrid es [INFO] Ongrid test. O configura una keyword que matchee (Ongrid funciona) o elige modo signed.

Quirks

at no está soportado

El sender actual envía msgtype: text puro. Mencionar a un usuario específico (atMobiles / atUserIds / isAtAll) no está en el builder de payload todavía. Añádelo vía el webhook genérico si lo necesitas hoy; el soporte nativo es un futuro enhancement.

Reintento en 4xx es intencional

DingTalk devuelve HTTP 200 incluso para fallos a nivel de protocolo (mismatch de firma, mensaje demasiado largo, rate-limit del bot), con un errcode en el JSON body. El sender trata cualquier 2xx como éxito y solo muestra los status codes HTTP no-2xx. Si el bot deja de entregar silenciosamente, revisa el log del manager por dingtalk: send_text: code=… — Feishu y DingTalk comparten el mismo patrón de "200 OK + errcode en body".

Rate-limit de mensajes de DingTalk

DingTalk topa los mensajes de bot custom en 20 por minuto por bot. El dampening del pipeline de alertas (default 5m por dedupe key) usualmente se mantiene bien por debajo; clusters de alta cardinalidad pueden necesitar una ventana de dampening más alta o routing por-regla de canal.

Comparación con Feishu

Aspecto	DingTalk	Feishu
Query / body firmados	URL query (timestamp, sign)	Campos del body (timestamp, sign)
Unidad de timestamp	Milisegundos	Segundos
Signing key	secret	timestamp + "\n" + secret
Algoritmo HMAC	SHA-256	SHA-256
Body vacío firmado	No (el sign es sobre stringToSign)	Sí (el mensaje HMAC está vacío)

Dos protocolos superficialmente similares, tres diferencias reales. Existen en Senders separados exactamente por esta razón.

Relacionado

• Webhook — para protocolos que Ongrid no habla nativamente (app Wecom Mass, Microsoft Teams, Mattermost, Rocket Chat, OpsGenie, PagerDuty…).
• Overview de canales — la forma unificada notify.Message que consume cada Sender.