Roboflow Vision Events¶

Send images, model predictions, and event metadata to the Roboflow Vision Events API for monitoring, quality control, safety alerting, and custom event tracking.

How This Block Works¶

This block uploads workflow images and model predictions to the Roboflow Vision Events API, creating structured events that can be queried, filtered, and visualized in the Roboflow dashboard.

1. Optionally uploads an input image and/or output image (visualization) to the Vision Events image storage via the public API
2. Converts model predictions (object detection, classification, instance segmentation, or keypoint detection) into the Vision Events annotation format and attaches them to the input image
3. Creates a vision event with the specified event type, use case, event data, and custom metadata
4. Enforces a built-in rate limit (cooldown_seconds, default 1 second) so high-frequency video workflows do not flood the API with an event per frame
5. Supports fire-and-forget mode for non-blocking execution

Rate Limiting¶

Video workflows can run many times per second, which by default would send an event (and its images) for every frame. To prevent this, the block enforces a cooldown between consecutive events: at most one event per second is sent by default. Events triggered during the cooldown period are dropped and the throttling_status output is set to True.

Adjust cooldown_seconds to your needs, or set it to 0 to disable rate limiting entirely (e.g. for intentionally bursty use cases). The cooldown timer lives in the block instance, so it throttles long-lived executions such as video processing with InferencePipeline. Workflows served over HTTP (e.g. /workflows/run) create fresh block instances per request, so the cooldown does not throttle across separate HTTP calls.

Deployment Modes¶

By default this block sends events to the Roboflow Vision Events API (cloud / Serverless API), uploading images and posting the event over the public API.

For edge deployments, enable Write to Local Event Store to send events to a local Event Ingestion Service instead. In this mode images are embedded directly in the request (no upload step) and the event is posted to <event store URL>/v2/events. The event store URL defaults to http://localhost:8001 and can be overridden. No Roboflow API key is required in this mode; if the local service requires authentication, set the EVENT_INGESTION_API_KEY environment variable on the inference server.

Event Types¶

• quality_check: Manufacturing/inspection QA with pass/fail result and optional confidence
• inventory_count: Inventory tracking with location, item count, and item type
• safety_alert: Safety violations with alert type, severity (low/medium/high), and description
• custom: User-defined events with a free-form value string
• operator_feedback: Operator review/correction of previous events (correct/incorrect/inconclusive)

Requirements¶

The default (cloud) mode requires a valid Roboflow API key with vision-events:write scope, configured in your environment or workflow configuration. No Roboflow API key is needed when Write to Local Event Store is enabled (see Deployment Modes above).

Common Use Cases¶

• Quality Control: Automatically log inspection results with images and detection overlays
• Safety Monitoring: Send safety alerts when violations are detected in video streams
• Production Analytics: Track inventory counts and production metrics with visual evidence
• Active Monitoring: Fire-and-forget event logging from real-time video processing workflows

Type identifier¶

Use the following identifier in step "type" field: roboflow_core/roboflow_vision_events@v1to add the block as as step in your workflow.

Properties¶

The Refs column marks possibility to parametrise the property with dynamic values available in workflow runtime. See Bindings for more info.

Runtime compatibility¶

soft — runtime hosted_serverless, dedicated_deployment; execution remote

Cooldown / rate-limit timer is stored in process memory. With remote step execution on stateless or multi-replica HTTP runtimes each request gets a fresh worker, so cooldown does not throttle. Cooldown only behaves as documented with local step execution inside an InferencePipeline.

Available Connections¶

Input and Output Bindings¶

The available connections depend on its binding kinds. Check what binding kinds Roboflow Vision Events in version v1 has.

{
    "name": "<your_step_name_here>",
    "type": "roboflow_core/roboflow_vision_events@v1",
    "input_image": "$inputs.image",
    "output_image": "$steps.visualization.image",
    "predictions": "$steps.object_detection_model.predictions",
    "event_type": "quality_check",
    "solution": "my-use-case",
    "external_id": "batch-2025-001",
    "qc_result": "pass",
    "location": "warehouse-A",
    "item_count": 42,
    "item_type": "widget",
    "alert_type": "no_hardhat",
    "severity": "high",
    "alert_description": "Worker detected without hardhat in zone B",
    "custom_value": "anomaly detected at 14:32",
    "related_event_id": "evt_abc123",
    "feedback": "correct",
    "custom_metadata": {
        "camera_id": "cam_01",
        "location": "$inputs.location"
    },
    "fire_and_forget": true,
    "disable_sink": false,
    "cooldown_seconds": 1,
    "write_to_event_store": false,
    "event_store_url": "http://localhost:8001"
}