Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly documented as a Superagnt data API, but it exposes broader web/SEO tooling and persistent webhook handling than the social-data framing clearly suggests.
Install only if you intend to let agents send social, web, SEO, and webhook data to Superagnt. Treat webhook receive URLs like credentials, do not rely on them as proof an event is genuine, validate vendor payloads before acting, and avoid using this skill for sensitive profile, business, or third-party data without authorization and retention controls.
### Concepts - **Endpoint** — a named receiver in the user's workspace. Created with a friendly `name` (e.g. `stripe-prod`); identified by a UUID `id`. - **Receive URL** — `https://api.superagnt.com/webhooks/ingest/<endpointId>`. The endpoint id IS the secret in the URL — treat it like a credential. There is no signature verification; the URL is the auth. - **Delivery** — one inbound POST, captured with the raw JSON body, the headers the third party sent, and the source IP. Has an `acknowledgedAt` timestamp that starts `null`. - **Acknowledge** — mark a delivery as processed so it stops appearing in `unacknowledged: true` queries. Does NOT delete the delivery; history is retained.
### Typical Agent Flow
1. **Create the endpoint** — `POST /v1/webhook-endpoints` with `{ "name": "stripe-prod" }`. Returns `{ id, name, url }`. Show the `url` to the user and tell them to paste it into the third party's webhook configuration.
2. **Wait for events** — the third party POSTs to `https://api.superagnt.com/webhooks/ingest/<id>`. Each POST is stored as a delivery; nothing is forwarded synchronously.
3. **Poll for new work** — `GET /v1/webhook-endpoints/deliveries?unacknowledged=true&endpointId=<id>` (or omit `endpointId` to query across all endpoints in the workspace).
4. **Process each `rawPayload`** — it's the exact JSON the vendor sent. Parse it the way that vendor documents (e.g. for Stripe, switch on `type` and read `data.object`).
5. **Acknowledge** — call `POST /v1/webhook-endpoints/deliveries/ack` with `{ "ids": [...] }` (or single via `POST /v1/webhook-endpoints/deliveries/{id}/ack`) so the next poll doesn't re-deliver them.| Method | Path | Summary |
|--------|------|---------|
| `POST` | `/v1/webhook-endpoints` | Create a new superagnt webhook endpoint. Returns { id, name, url } where `url` is a public HTTPS endpoint of the form https://api.superagnt.com/webhooks/ingest/<id>. Give that URL to a third party (Stripe, Calendly, GitHub, your own service, etc.) so they can POST events to it. superagnt stores every inbound POST as a "delivery" the agent can later fetch with superagnt_webhooks_list_deliveries. The `name` is a workspace-unique label (3-50 chars, lowercase + hyphens) that you can show to the user; it is NOT part of the receive URL. Use this when the user asks to "set up a webhook", "give me a URL to receive events", or "let me ingest events from <vendor>". |
| `GET` | `/v1/webhook-endpoints` | List every active webhook endpoint in the workspace. Returns an array of { id, name, description, isActive, createdAt, updatedAt }. Use the `id` from any item as `endpointId` for superagnt_webhooks_get_endpoint, superagnt_webhooks_delete_endpoint, or superagnt_webhooks_list_deliveries. Use this to discover existing endpoints before creating a new one or to show the user their current webhook configuration. |
| `GET` | `/v1/webhook-endpoints/{id}` | Get full details of a single webhook endpoint by id. Returns { id, name, description, isActive, createdAt, updatedAt }. Use this when you have an endpoint id (e.g. from superagnt_webhooks_list_endpoints) and need its full record. Note: this does NOT return the receive URL — reconstruct it as https://api.superagnt.com/webhooks/ingest/{id} if you need to show it again. |
| `DELETE` | `/v1/webhook-endpoints/{id}` | Soft-delete (deactivate) a webhook endpoint by id. After deletion the receive URL https://api.superagnt.com/webhooks/ingest/{id} stops accepting POSTs (returns 404). Existing delivery history is retained and still queryable. Use this when the user wants to stop receiving events on an endpoint or rotate to a new one. ALWAYS confirm wit
...[truncated 24 chars]|--------|------|---------|
| `POST` | `/v1/webhook-endpoints` | Create a new superagnt webhook endpoint. Returns { id, name, url } where `url` is a public HTTPS endpoint of the form https://api.superagnt.com/webhooks/ingest/<id>. Give that URL to a third party (Stripe, Calendly, GitHub, your own service, etc.) so they can POST events to it. superagnt stores every inbound POST as a "delivery" the agent can later fetch with superagnt_webhooks_list_deliveries. The `name` is a workspace-unique label (3-50 chars, lowercase + hyphens) that you can show to the user; it is NOT part of the receive URL. Use this when the user asks to "set up a webhook", "give me a URL to receive events", or "let me ingest events from <vendor>". |
| `GET` | `/v1/webhook-endpoints` | List every active webhook endpoint in the workspace. Returns an array of { id, name, description, isActive, createdAt, updatedAt }. Use the `id` from any item as `endpointId` for superagnt_webhooks_get_endpoint, superagnt_webhooks_delete_endpoint, or superagnt_webhooks_list_deliveries. Use this to discover existing endpoints before creating a new one or to show the user their current webhook configuration. |
| `GET` | `/v1/webhook-endpoints/{id}` | Get full details of a single webhook endpoint by id. Returns { id, name, description, isActive, createdAt, updatedAt }. Use this when you have an endpoint id (e.g. from superagnt_webhooks_list_endpoints) and need its full record. Note: this does NOT return the receive URL — reconstruct it as https://api.superagnt.com/webhooks/ingest/{id} if you need to show it again. |
| `DELETE` | `/v1/webhook-endpoints/{id}` | Soft-delete (deactivate) a webhook endpoint by id. After deletion the receive URL https://api.superagnt.com/webhooks/ingest/{id} stops accepting POSTs (returns 404). Existing delivery history is retained and still queryable. Use this when the user wants to stop receiving events on an endpoint or rotate to a new one. ALWAYS confirm with the user before deleting —
...[truncated 26 chars][
{
"name": "superagnt_webhooks_create_endpoint",
"description": "Create a new superagnt webhook endpoint. Returns { id, name, url } where `url` is a public HTTPS endpoint of the form https://api.superagnt.com/webhooks/ingest/<id>. Give that URL to a third party (Stripe, Calendly, GitHub, your own service, etc.) so they can POST events to it. superagnt stores every inbound POST as a \"delivery\" the agent can later fetch with superagnt_webhooks_list_deliveries. The `name` is a workspace-unique label (3-50 chars, lowercase + hyphens) that you can show to the user; it is NOT part of the receive URL. Use this when the user asks to \"set up a webhook\", \"give me a URL to receive events\", or \"let me ingest events from <vendor>\".",
"method": "POST",
"path": "/v1/webhook-endpoints",
"parameters": {},
{
"name": "superagnt_webhooks_list_deliveries",
"description": "Fetch the most recent webhook deliveries for the workspace, newest first. This is THE tool to use to \"check for new webhook events\", \"process incoming webhooks\", or \"see what a third party sent\". Returns { deliveries: [{ id, webhookEndpointId, rawPayload, headers, sourceIp, acknowledgedAt, createdAt }], nextCursor }. `rawPayload` is the exact JSON body the third party POSTed to https://api.superagnt.com/webhooks/ingest/<id> — parse it the way that vendor documents (e.g. for Stripe inspect `type` and `data.object`). Workflow: (1) call this with `unacknowledged: true` to get only un-processed deliveries, (2) handle each `rawPayload`, (3) call superagnt_webhooks_ack_delivery (or superagnt_webhooks_ack_deliveries for batch) with the delivery `id`s so they don't come back next poll. If `nextCursor` is non-null, pass it as `cursor` on the next call to page through older deliveries.",
"method": "GET",
"path": "/v1/webhook-endpoints/deliveries",
"parameters": {Create an endpoint:
```bash
curl -X POST https://api.superagnt.com/v1/webhook-endpoints \
-H "Authorization: Bearer $SUPERAGNT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "stripe-prod", "description": "Stripe events for production"}'## Example
```bash
curl -X POST "https://api.superagnt.com/v1/data/seo/serp" \
-H "Authorization: Bearer $SUPERAGNT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"key": "value"}'## Example
```bash
curl -X POST "https://api.superagnt.com/v1/data/web/scrape" \
-H "Authorization: Bearer $SUPERAGNT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"key": "value"}'# X (Twitter) API Reference **App name:** `x` **Base URL:** `https://api.superagnt.com/v1/data/x` **Endpoints:** 52 Unified access to tweets, user profiles, followers, search, and hashtag streams. Built for LLMs and automation — not one-off scraping.
## Example ```bash curl -X GET "https://api.superagnt.com/v1/data/x/user/medias/continuation?param=value" \ -H "Authorization: Bearer $SUPERAGNT_API_KEY" ```
# YouTube API Reference **App name:** `youtube` **Base URL:** `https://api.superagnt.com/v1/data/youtube` **Endpoints:** 24 Unified access to video metadata, channel discovery, comments, subtitles, and recommendations. Built for LLMs and automation — not one-off scraping.
# YouTube API Reference **App name:** `youtube` **Base URL:** `https://api.superagnt.com/v1/data/youtube` **Endpoints:** 24 Unified access to video metadata, channel discovery, comments, subtitles, and recommendations. Built for LLMs and automation — not one-off scraping.
No suspicious patterns detected.