> ## Documentation Index
> Fetch the complete documentation index at: https://docs.secapi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# POST /v1/monitors

> Create a saved-search monitor with optional webhook or email delivery destination

Create a saved-search monitor with optional webhook or email delivery destination

<Info>
  Audience: signed-in organization administrator.
</Info>

## Creation constraints

A monitor requires a non-empty `name` and `query`. Choose one destination model: the legacy `webhookUrl` field and `delivery` cannot be sent together. Email delivery and certain event subscriptions can require account activation; preserve `Retry-After` on a throttled response.

`startAt` defines the initial search boundary for ordinary saved searches. Structured search modes are validated against their own filter schema and may be unavailable. Creating a monitor records configuration; it is not a guarantee of a polling interval, match volume, or successful downstream delivery.

## Canonical metadata

* `requestId`
* `traceparent`

## Example request

<RequestExample>
  ```bash theme={null}
  curl -X POST \
    -H "Authorization: Bearer $SECAPI_BEARER_TOKEN" \
    -H "secapi-version: 2026-03-19" \
    -H "content-type: application/json" \
    -d '{"name":"Example filings monitor","query":"material agreement"}' \
    "https://api.secapi.ai/v1/monitors"
  ```
</RequestExample>

<Info>
  This organization control-plane action requires a signed-in WorkOS browser session. Do not give an API key or an autonomous agent authority to create, change, test, replay, rotate, or delete it.
</Info>

## Example response

<ResponseExample>
  ```json theme={null}
  {
    "requestId": "req_2ZK8Q1W9F4M6P7R3"
  }
  ```
</ResponseExample>

## Give this prompt to your agent

<Prompt>
  Explain the required fields for POST /v1/monitors, but direct the user to complete the change in the signed-in SEC API dashboard. Do not attempt the mutation with an API key or an autonomous agent. Preserve requestId and traceparent when the dashboard or a human-authenticated session returns them.
</Prompt>

## Failure posture

* treat non-2xx responses as contract-aware failures, not free-form errors
* preserve `requestId` and `traceparent` in logs and downstream reports
* if provenance or freshness metadata is present, return it unchanged so trust is not lost in the handoff