Skip to main content

​
Real-Time Frequency

The frequency_minute parameter controls how often your monitor scans.
SettingBehaviorUse Case
0 (default)Real-time — signals are detected and delivered as they appearMost monitors — fastest possible delivery
1 - 60Fixed interval in minutesWhen you want predictable cadence
60 - 1440Hourly to dailyDigest-style summaries, lower priority signals
With frequency_minute: 0, Pubrio detects and delivers signals as they appear — no polling, no delay.

​
Retry Configuration

When a webhook delivery fails, retries help recover automatically.
ParameterRangeDefaultRecommendation
max_retry_per_trigger0 - 31Set to 2-3 for critical monitors
retry_delay_second1 - 51Use 3-5 seconds to allow transient issues to resolve
Retries re-deliver the same payload — they do not re-run the signal detection or incur additional search credits.

​
Process Retry

The Process Retry endpoint lets you re-attempt a specific failed delivery. Key benefits:
  • No charge for failures — you are not charged credits when a delivery fails. Credits are only consumed on successful delivery.
  • Troubleshooting — retry a failed log entry to diagnose webhook issues without creating new triggers.
  • Original destination option — use is_use_original_destination to retry with the destination snapshot from the original log, useful when you have updated your webhook URL since the failure.
Find failed deliveries via Statistic Logs and retry them individually.

​
Failure Handling

The max_failure_trigger parameter (range: 1-10, default: 5) controls how many consecutive delivery failures are allowed before the monitor automatically pauses. Recommended approach:
  1. Set notification_email to receive alerts when failures occur
  2. Keep max_failure_trigger at 3-5 for production monitors
  3. Use Statistic Logs to diagnose failures — check error_message and response_status_code
  4. After fixing the issue, reactivate via Update Monitor
  5. Use Process Retry to re-attempt specific failed deliveries

​
Polling with Statistics Endpoints

While webhooks handle real-time delivery, the statistics endpoints provide monitoring, debugging, and audit capabilities.

​
Overview polling

Use Monitor Statistics for a dashboard-level health check: 
curl -X POST https://api.pubrio.com/monitors/statistics \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{ "profile_id": 1 }'
Returns aggregate metrics: total monitors, triggers today vs yesterday, success rates, and comparison rates.

​
Log-based polling

Use Statistic Logs to review trigger history: 
curl -X POST https://api.pubrio.com/monitors/statistics/logs \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "profile_id": 1,
    "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "page": 1,
    "per_page": 10
  }'
Each log entry includes status, credit usage, signal/company/people counts, processing time, and error details.
Combine webhook delivery with periodic log polling for maximum reliability: webhooks handle real-time processing, while log polling catches any missed deliveries and provides an audit trail.

​
Scaling Recommendations

Prefer focused monitors over overly broad ones. A monitor tracking “AI jobs at US enterprise companies” is easier to debug than “all jobs everywhere.” Focused monitors also let you route different signal types to different webhook endpoints.
Your webhook endpoint should:
  • Respond within 30 seconds
  • Return 200 immediately and process data asynchronously
  • Handle duplicate payloads gracefully (idempotency)
  • Log all incoming payloads for debugging
Use Get Monitor List with filtering:
  • Filter by detection_mode and destination_type
  • Sort by last_modified or last_trigger_at
  • Search by name with search_term
Use Monitor Statistics to spot underperforming monitors quickly.