.svg?fit=max&auto=format&n=cJUhKEokp8h2t8Ke&q=85&s=2192fe0b4406e259cba34cdda8acffdc)
Delivery: email and webhooks
Delivery settings decide where DarknetSearch sends what it finds — email, a webhook, or both. They’re org-level resources you configure once, up front, then reference byid wherever delivery is needed (today, that’s monitoring rules, which send each new match to them). Email uses three pieces — a sender (the SMTP account it’s sent from), recipients (the addresses it goes to), and a template (subject and body). A webhook is a single signed HTTP POST.
Two rules apply across all four resource types: each organization has exactly one default of each (setting a new default unsets the old one), and a resource can’t be deleted while a rule references it — detach or delete those rules first.
Recipients
A recipient is just an address. List withalert_system_setting_get_recipient_list, create with alert_system_setting_create_recipient, delete with alert_system_setting_delete_recipient.
email, is_default. Up to 10 recipients per organization.
Senders
A sender is the SMTP account matches are sent from. List withalert_system_setting_get_sender_list, create with alert_system_setting_create_sender, delete with alert_system_setting_delete_sender.
Up to 10 senders per organization. Send a test before you rely on one with
alert_system_setting_test_email — POST {"sender_id": 8, "recipient": "soc@acme.com"}; it returns 202 and sends asynchronously.
**`encryption_method` only acts on `TLS`.** A `TLS` sender issues `STARTTLS` before authenticating; an `SSL` sender currently connects in plaintext (no implicit TLS wrapper). Use `TLS` for an encrypted connection.
Email templates
A template is the subject and HTML body of the email. List withalert_system_setting_get_template_list, create with alert_system_setting_create_template, edit with alert_system_setting_update_template, delete with alert_system_setting_delete_template.
Fields: name, subject, body (HTML), is_default. The body must contain these placeholders, or create/update is rejected:
{current_date} · {alert_rule_name} · {number_of_hits} · {service} · {match_detail_link}
At send time those are substituted in both subject and body, along with two optional extras — {total_results} (all hits) and {excluded_count}. {number_of_hits} is the non-excluded count, and {match_detail_link} links straight to the incident in the dashboard.
Webhooks
A webhook delivers each match as one HTTPPOST. List with alert_system_setting_get_webhook_list, create with alert_system_setting_create_webhook, edit with alert_system_setting_update_webhook, delete with alert_system_setting_delete_webhook.
name, url (≤2048 chars), headers (a JSON object sent on every delivery), is_default, and a read-only secret. Up to 10 webhooks per organization. The secret is server-generated and read-only — any value you send is ignored, and the response carries the real one. To rotate it, delete and recreate the webhook.
The payload. The body is compact JSON, delivered with a 30-second timeout and no retry (any 2xx is treated as success):
hooks.slack.com), Discord (discord.com/api/webhooks), and Microsoft Teams (webhook.office.com/outlook.office.com) get their native message formats; every other URL gets the generic payload above. It carries the rule, the source, the match counts, and a link — not the hits themselves; fetch those from the match.
The signature. When the webhook has a secret, every request carries X-AlertSystem-Signature: sha256=<hex>, an HMAC-SHA256 of the raw request body keyed with your secret. Verify it: strip the sha256= prefix, recompute the HMAC over the exact bytes you received, and compare in constant time. Reject mismatches; return a 2xx to acknowledge. Two custom headers are always present too: Content-Type: application/json and User-Agent: AlertSystem/1.0.