Keep listening

After the first search you can keep a signal running. There are four ways, from the simplest to the most automatic.

Run the search again#

Any signal you follow by running its search again, for example every week: search_signals, or POST /searches. A new search charges every row it returns, also rows an earlier search returned, so keep its window short: lookback_days 7 on engagement, window_days 7 on funding rounds, and signal.exclude_domains for the technology companies you already have. There are no watches.

Keyword monitors#

A monitor reads the LinkedIn posts that use your keywords on a schedule and keeps each new one as a mention. create_monitor is POST /monitors. Creating it is free; each new mention on a run is 1 credit, within the monitor's max_credits_per_day. POST /monitors/preview is free. The default schedule is daily; hourly stays off unless that deployment has turned it on.

• list_mentions (GET /mentions) is free; each mention names its author with their LinkedIn URL and headline, so you can save or enrich them.
• manage_monitor lists, changes, pauses, resumes and deletes a monitor, for free (GET /monitors, PATCH and DELETE /monitors/{monitor_id}): change its keywords, cap, relevance or tags any time, and see what its last run did. A deleted monitor stops for good; its mentions stay readable for 30 days.
• A monitor sends no webhooks: read its new mentions with list_mentions. Idempotency-Key is optional on a monitor.

The monitor tools return a dashboard_url: /en/gtm/views/signals?monitor=mon_….

Your own signals#

Your agent can also watch things mySDR does not: hiring spikes on careers pages, posts on X, a newsletter, a list in the CRM. Register each one and the user sees it on the Signals tab next to the signals mySDR runs. mySDR does not run or schedule it, and it costs nothing.

• Register with save_agent_signal (POST /agent-signals) under a key you choose (hiring_spike): a name, what it watches, where, and how often. The same key again updates it; status paused stops it.
• After every check, report it with log_signal_hits (POST /agent-signals/{key}/hits): when you checked, when you check next, and each person or company it caught with what you saw and source_url. They land in Leads or Companies with the signal in the Signals column, and on the Activity tab.
• Read back with ?agent_signal={key} on GET /tables/* (list_table). list_agent_signals (GET /agent-signals) at the start of a session says which to run; skip the paused ones.

Webhooks#

mySDR can POST events to an HTTPS URL you choose, for the searches of the Signals API. There is no webhook for a new lead in the mySDR app, a reply in the Inbox, a template edit, or a call to the assistant MCP server at https://mysdr.app/api/mcp. For LinkedIn outreach, poll get_outreach_events (or GET /outreach/linkedin/events) with its cursor.

POST https://mysdr.app/api/v1/webhook_endpoints needs Authorization: Bearer gtk_… and a required Idempotency-Key. The secret comes back once. An organization can have 5 endpoints. POST …/test sends a ping. Your URL must answer 2xx within 10 seconds. mySDR retries up to 8 attempts.

Subscribe with these type values: search.completed, search.failed. ping is not in that list. The test call sends it anyway.

Every delivery has mySDR-Event-Id, mySDR-Event-Type, and mySDR-Signature: t=<unix seconds>,v1=<hex>. The User-Agent is mySDR-Webhooks/1.0. v1 is HMAC-SHA256 of <t>.<raw body> with the endpoint secret. Reject a timestamp more than 300 seconds off. The envelope api_version is 2026-10-04. A missing key on these routes is 401. A valid key while Signals is turned off answers 403 api_not_enabled. Creating an endpoint does not spend credits. The endpoint pages are under Create a webhook endpoint.