Skip to main content
Use Make when one saved filing-monitor match should become several operational actions. SEC API delivers a signed monitor.match event; Make’s Iterator turns data.matches into one bundle per filing. The scenario routes evidence. It does not decide whether a filing is material, adverse, or actionable.

​
Prerequisites

  • A Make account and a scenario with a production Custom webhook trigger for trusted, forwarded events.
  • A public HTTPS receiver you control that can verify the raw webhook body before forwarding an accepted event to Make.
  • A signed-in SEC API organization administrator. Endpoint and monitor setup use the Delivery dashboard, not an API key.
  • SECAPI_API_KEY only for the read-only monitor preview below.

​
1. Configure signed delivery

  1. Build the small verification receiver described in Build a filing monitor. It must retain the raw request body, verify SEC API’s HMAC signature, reject invalid events, and forward only accepted events to Make’s Webhooks > Custom webhook URL.
  2. In the Delivery dashboard, create an organization webhook endpoint with the verification receiver’s HTTPS URL and subscribe it to monitor.match.
  3. In the same dashboard, create a narrowly scoped monitor with a query, form filter, and ticker list, then connect it to that endpoint.
Save the dashboard-issued signing secret in the receiver’s secret store. SEC API must post to the receiver, not directly to Make. Do not expose the signing secret in Make scenario fields; Make should receive only the receiver’s accepted, normalized event.

​
2. Split each filing into a bundle

  1. Put Tools > Iterator after the accepted event and set its array to data.matches.
  2. Map data.monitor.name, ticker, form, filingDate, and htmlUrl into Slack, email, Sheets, or a review queue.
  3. Include the monitor name and htmlUrl in the destination. htmlUrl is the path back to the source filing.
The expected production event has type monitor.match and can contain zero or more matched filings. A dashboard test produces webhook.test; acknowledge it to prove delivery, but do not create a filing-review task from it.

​
3. Preview the saved query

The response is a point-in-time match lookup for the configured monitor. Preserve the returned requestId and source URL with any Make-created record so a reviewer can trace the alert.

​
Source and provenance

The trusted receiver should forward the accepted event id, request ID, monitor name, filing identity, and htmlUrl to Make. Keep those values on the destination record so the workflow can be deduplicated and the reviewer can reopen the matched SEC filing. A dashboard webhook.test is delivery evidence only.

​
Limits and failure modes

  • API-key attempts to create, edit, test, replay, rotate, or delete monitor/webhook configuration return human_auth_required; use the signed-in dashboard.
  • A scenario that consumes data.matches[] without an Iterator may produce one aggregate task rather than one filing task.
  • A monitor.match proves a query matched text; it does not prove materiality or a completed analyst review.
  • Retries can deliver the same event more than once. Use the event id as an idempotency key in the trusted receiver or destination.

​
Next step

Use Build a filing monitor for the raw-body signature verification and production receiver pattern.