EngageLab App Push
ReviewAudited by ClawScan on May 18, 2026.
Overview
This is a coherent EngageLab API helper, but it can use a master secret to send, schedule, recall, and delete push-related data, so high-impact actions should be explicitly confirmed.
Use this skill only if you control the EngageLab app. Confirm the target audience, message body, schedule, and any delete/recall action before execution; keep the master secret private; use only official EngageLab API domains; and enable HMAC verification for callbacks.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken or unauthorized request could send notifications to many users, create future sends, recall messages, or delete push-user data.
The skill exposes high-impact API operations that can message large audiences, create persistent scheduled sends, or delete device/user data. These operations are disclosed and aligned with the stated EngageLab push-management purpose, but they warrant explicit user review.
Create Push — Send notification or message ... broadcast ... Scheduled Tasks — Create, get, update, delete scheduled push tasks ... Delete User — Delete a user (registration_id) and all associated data
Confirm the exact app, audience, message content, schedule, and destructive action before executing these APIs; use the validate/test endpoint before real sends when possible.
Anyone with the master secret may be able to perform push operations for the application through EngageLab APIs.
The AppKey and Master Secret are sensitive credentials that authorize EngageLab API actions. This is expected for the integration, but users should treat the master secret as account-level authority.
Authorization: Basic base64(appKey:masterSecret) ... If the user hasn't provided credentials, ask for AppKey and Master Secret before generating API calls.
Provide credentials only when needed, use the correct EngageLab data-center domain, avoid sharing secrets in chat history where possible, and rotate the master secret if exposure is suspected.
If callback signatures are not verified, a third party could potentially send fake delivery or click events to the user's server.
The callback flow involves webhook-style messages carrying delivery/click event data, and authenticity verification is described as optional. This is normal integration documentation, but unverified callbacks could be spoofed.
Security (optional) ... verify the X-CALLBACK-ID header ... signature = HMAC-SHA256(secret, timestamp + nonce + username)
Configure a callback username and secret, verify the HMAC signature on every callback, check timestamps/nonces where possible, and make callback handling idempotent.