/v1/parallel/monitors

Parallel Monitors. A Parallel monitor watches the web for you: you give it a question in plain words, such as "New releases or security advisories of the PostgreSQL database", and a schedule from every hour to every 30 days. Each scheduled run (an execution) searches the web and records an event when it finds something new and material. You read the events whenever you like. A monitor runs until you cancel it, or until RouterPlus stops it because it can no longer be paid for (see When a monitor is stopped).

The field names are Parallel's, so Parallel's Monitor docs apply to the body you send, within the limits below.

Who can use it

An organization API key of a paid organization: a key you created in API keys for an organization that has added paid credit. Playground and evaluation keys, and organizations still on the free trial, get 403 forbidden: "Parallel Monitors need an organization API key from a paid organization: create one in API keys and add paid credit in Billing". Nothing is reserved or sent.

Monitor executions are billed to your organization's credit. A key limited to your own provider keys or to a routing policy cannot spend it, so a create, an update or a trigger with such a key is a 403 forbidden too: "This API key is limited to its own provider keys or a routing policy, and Parallel Monitors are billed to marketplace credit: use an organization API key without that limit. A routing policy set on the organization or workspace applies to every key, so an owner must change it in the console". Nothing is reserved or sent. Reads, lists, events and cancels are unchanged.

Prices

Parallel's list price for the processor, per execution, with no markup. Every execution is billed, whether it found something or not:

core is not offered. A failed execution (an error event) is not billed.

What a monitor costs: executions in a period × the price. A 1h lite monitor runs 24 times a day: 24 × 30 = 720 executions in 30 days, $2.16. The same monitor at 1d is 30 executions, $0.09; at 1h on base, 720 × $0.01 = $7.20. Each trigger is one more execution, and creating a monitor runs it once at once.

How the money moves:

• The credit check. Creating a monitor needs credit for 24 hours of its executions: ceil(86400 / frequency in seconds) + 1 executions at its price, held for a moment and released (a 1h lite monitor: 25 × $0.003 = $0.075). Without that credit the create is a 402 insufficient_credit and nothing runs. The check is run again every 24 hours while the monitor runs, and when you change its frequency or processor.
• The charge. RouterPlus reads each monitor's events at least once an hour and charges every execution it has not charged before, once, at the price of the processor it ran on. Each execution is one attempt in GET /v1/usage & /v1/generation: provider parallel, model parallel:monitor:<processor>, the price as server_tool_fee_usd. So a charge can appear up to an hour after the execution ran.
• After a stop. An execution still running when a monitor is stopped (by you or by RouterPlus) is charged when it finishes: RouterPlus keeps reading a stopped monitor's events for 15 minutes (first after 60 seconds, then every 5 minutes) and charges what it has not charged yet. Nothing new starts after the stop.
• Never below zero. An execution that cannot be charged (no credit left, a spend cap reached, the key disabled, or past spend_limit_usd) is not charged at all, and the monitor is stopped in the same pass.
• Your spend limit. spend_limit_usd (default $10) caps what one monitor can charge: when the next execution would pass it, the monitor is stopped.
• The monitor's charged_usd and executions_charged say what it has charged so far.

Create a monitor

curl https://api.routerplus.com/v1/parallel/monitors \
  -H "Authorization: Bearer $TM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "event_stream", "frequency": "1d", "processor": "lite",
       "settings": {"query": "New releases or security advisories of the PostgreSQL database"},
       "spend_limit_usd": 2}'

201, with the monitor:

{"id": "pmon_6f0c1e2d3a4b5c6d7e8f901a2b3c4d5e", "object": "parallel.monitor", "status": "active",
 "type": "event_stream", "frequency": "1d", "processor": "lite",
 "query": "New releases or security advisories of the PostgreSQL database",
 "spend_limit_usd": 2, "charged_usd": 0, "executions_charged": 0,
 "last_run_at": "2026-11-06T01:40:24.767Z", "created_at": "2026-11-06T01:40:24.512Z",
 "cancelled_at": null, "cancel_reason": null}

The body, at most 32 KB:

Refused with a 400 invalid_request that names the field, before anything is held or sent:

Read and list

GET /v1/parallel/monitors/{id} answers the monitor:

GET /v1/parallel/monitors lists your organization's monitors, newest first: ?limit= 1 to 100 (default 20), ?status= creating, active, cancelled or failed, and ?cursor= the next_cursor of the previous page.

An unknown id, a malformed id and another organization's monitor all get the same 404 not_found: monitor "<id>" not found.

Read events

GET /v1/parallel/monitors/{id}/events reads what the monitor found, newest first:

{"object": "list", "next_cursor": null, "events": [
 {"event_id": "...", "event_group_id": "mevtgrp_...", "event_date": "2026-11-05", "event_type": "event_stream",
  "output": {"type": "text", "content": "PostgreSQL 18.1 was released ...",
             "basis": [{"field": "output", "citations": [{"url": "https://www.postgresql.org/...", "title": "...", "excerpts": ["..."]}],
                        "reasoning": "...", "confidence": "high"}]}},
 {"event_type": "completion", "timestamp": "2026-11-06T01:40:25.175Z"}]}

• One execution gives one of: one or more event_stream events sharing an event_group_id (it found something); one completion event (it found nothing, listed only with include_completions=true); one error event (it failed: error_message is always "the execution failed", and it is not billed).
• The event window: Parallel lists only about the 300 most recent executions of a monitor: at 1h that is about 12 days, at 1d about 10 months. Older events roll off without notice. Read the events of a frequent monitor at least every few days, and keep what you need: RouterPlus keeps no event.
• Events are fetched from Parallel each time you ask, including after the monitor is cancelled.
• While Parallel Monitors are off or being wound down on the gateway, every route, events included, answers 404 (see Troubleshooting). A page over 2 MB is a 502 too_large: ask for fewer with limit.
• Only the fields above are passed on.

Update, trigger, cancel

Update: POST /v1/parallel/monitors/{id}/update with any of frequency, processor, settings.query and spend_limit_usd; only what you send changes. An empty body or any other field is a 400. A new frequency or processor first runs the credit check for the new schedule on the key that created the monitor, which its executions are charged to (402 insufficient_credit changes nothing; a key that can no longer be charged is a 409 monitor_key_unusable), and the executions already run are charged at the old price. When those cannot be read and charged now, the update is a 503 gateway_error and nothing changes: retry after retry-after. A cancelled monitor cannot be updated: 409 monitor_cancelled.

Trigger: POST /v1/parallel/monitors/{id}/trigger runs the monitor once now and answers 202 with the monitor. It needs credit for one execution (402 otherwise) and room under spend_limit_usd (409 spend_limit_reached otherwise). The execution is charged to the key that created the monitor, so that key must still be usable: if it was disabled, the trigger is a 409 monitor_key_unusable, and RouterPlus stops the monitor on its next pass (within minutes). At most 5 triggers a day per monitor (a sixth is a 429 rate_limit until 00:00 UTC). A trigger Parallel refused (a 502 that says "nothing was charged") does not count. One Parallel did not confirm (a 502 that says it "did not confirm the execution") counts, since it may have run: read the events before triggering again. If Parallel answers that it no longer runs the monitor, the trigger is a 409 monitor_cancelled and the monitor is closed (upstream_cancelled). The execution is charged when RouterPlus reads it, like any other. A cancelled monitor: 409.

Cancel: POST /v1/parallel/monitors/{id}/cancel stops the monitor for good. RouterPlus first reads its events once more and charges the executions not yet charged, then stops it at Parallel, then answers 200 with the monitor (status: "cancelled", cancel_reason.code: "buyer_cancelled"). Cancelling again answers the same. If Parallel does not confirm the stop, the answer is a 502 cancel_failed: the monitor shows cancelling and RouterPlus keeps retrying the stop on its own; read the monitor to see it end.

When a monitor is stopped

RouterPlus stops a monitor at Parallel when it can no longer charge for it, and says why in cancel_reason:

An execution that ran but could not be charged is not billed to you.

RouterPlus does not notify you when it stops a monitor (no e-mail, no webhook): read the monitor (or list ?status=cancelled) and its cancel_reason. A monitor stopped with service_disabled cannot be read while Parallel Monitors are off on the gateway (every route answers 404); its cancel_reason shows once they are back.

Follow-up research

To research an event further, start a Parallel Task run: POST /v1/parallel/tasks/runs with the event's content in input. Monitor events cannot be chained into a Task with previous_interaction_id; send the context in input instead.

Limits

Errors

Parallel's own error text is never passed on.

Troubleshooting

• Every /v1/parallel/monitors path answers 404 not_found, like an unknown route. Parallel Monitors are not available on the gateway you called: either they are not enabled there, or they are being wound down (monitors that were running are being stopped and charged for what they ran). Check that you call the gateway your organization uses; if you expected Monitors there, contact support.
• 503 provider_unavailable: "Parallel Monitors are not set up on this gateway". The routes are enabled but not fully configured. Retrying will not help: contact support.
• 503 provider_unavailable: "Parallel Monitors are unavailable right now" or "Parallel is limiting new monitors". Parallel is refusing or limiting us for the moment. Nothing was charged; retry later.
• A monitor's status is cancelling. RouterPlus has stopped it and is confirming the stop with Parallel; it becomes cancelled on its own. Until then it is listed under ?status=active and counts toward your 10 active monitors.
• charged_usd lags behind last_run_at. Executions are charged when RouterPlus reads them, at least once an hour.

Data

• Your settings.query and settings.output_schema go to Parallel, a third party, with our Parallel key, for every execution. Under Parallel's standard terms it may use them and the events to improve its services. Our agreement with Parallel does not yet change that, so treat monitors as retained and possibly used for training by Parallel. Parallel stores data in the US. See Data policy.
• RouterPlus keeps, per monitor, ids, the schedule, the processor, the status, the spend limit, what was charged and times, and per execution its kind, time and charge: no query, schema, event, output or Parallel text. The create body is logged only if your organization has request logging on, as any request is. Events are never logged or kept.
• RouterPlus never sends memory_scope_key or webhook, and tags each monitor at Parallel with its own id and environment only.