Skip to main content
The monitoring API (watches, alerts, webhooks) is live, in beta. The core pipeline — ingestion sync → evaluation → alert → signed webhook delivery — runs in production and is what beta customers should build against. This page is the honest list of what is not there yet and the operational characteristics to design around.

​
Delivery modes: only always_per_alert

delivery_mode accepts only always_per_alert today — one delivery per alert. The digest modes (digest_above_threshold, digest_only) are planned but not yet available; sending them to create or update returns 400, and digest batching/suppression is not live for any watch. If you need batching today, do it on your side: dedupe by webhook-id and roll alerts up on your own schedule.

​
Alert latency: bounded by office sync cadence

An alert fires after the office publishes data → Signa ingests it → the evaluator matches it. Webhook delivery itself takes seconds after detection; the dominant term is the office’s publication-to-ingest gap. Concretely for the USPTO: Signa’s daily ingest runs at 01:01 UTC, with retry rails at 05:01 and 13:01 UTC that catch late upstream publication. A new US filing therefore typically alerts within ~24 hours of USPTO’s daily file publication — not within minutes of the filing itself. Other offices follow their own sync cadences (see Data freshness). Intra-day USPTO ingestion is on the roadmap but not committed.

​
Preview latency and the time budget

POST /v1/watches/preview runs synchronously under a ~20-second server-side budget, with each database read capped at 10 seconds:
  • mark and owner previews and narrow class previews complete in a few seconds. A broad watch without a text query (for example one class in US over 30 days) can hit the 10-second read cap and return a preview_timeout 504 after about 10 seconds.
  • similarity previews over broad scopes and long trial windows are the heaviest and may approach the budget.
  • Counts can come back labeled estimate_basis: "candidacy_upper_bound" (upper-bound estimate), the budget can end a heavy preview with a preview_timeout 504 (retryable: false — narrow the query), and concurrent previews 429 with a Retry-After. Full semantics on the Preview Watch page.

​
Diagnostics: bounded data windows

GET /v1/watches/{id}/diagnostics reconstructs the evaluation trace from retained provenance, and those retention windows are finite — change records 90 days, delivery audit records 30 days, indexing status 14 days, outbox 7 days. Past a horizon the response says so explicitly (evaluated: false with a reason, and the data_window object lists every horizon) rather than guessing. Diagnose recent misses promptly.

​
Logs page: origin-side only

The dashboard’s request Logs page records requests that reached the API origin. The rare error served directly from the CDN/WAF edge (an edge 5xx during a deploy or an edge block) does not appear there — and edge-served 502 bodies carry a fixed sentinel request_id (req_edge_static_502) rather than a real origin request id, because the request never produced one. For those, capture the x-amz-cf-id response header plus the timestamp, URL, and method, and email support@signa.so — that is enough for us to trace the edge hit. (WAF-generated 403/413 blocks and the edge rate-limit 429 carry the req_unknown sentinel, which is not traceable on its own — include the x-amz-cf-id header and timestamp for those too. An oversized URI returns 414, and oversized or malformed request headers return 400 from the load balancer or 494 when they exceed the CDN’s larger header cap, all with an HTML body and no sentinel at all; quote x-amz-cf-id for those as well.) The request_id in an error body is the thing to quote for JSON errors that came from the API origin itself.

​
No public status page yet

Signa does not currently publish a status page. Use the health endpoints for machine-readable liveness and readiness from your side (see Uptime monitoring), and support@signa.so for incident questions.

​
Webhook trademark identity

The alert.created payload carries the matched trademark at data.alert.trademark.id, matching the rich nested alert resource. The former root-level trademark_id and trademark_record_id fields are not present.

​
Events feed (beta)

The per-org event feed (GET /v1/events, GET /v1/events/{id}) is documented and callable. It is beta: the ledger, the evt_* ids and the sort=id&after= replay rail are stable enough to build on, but the per-event data payloads are versioned by payload_version and their shape is not yet promised. Pin payload_version in your consumer. Retention is 30 days; a checkpoint older than that returns 410 replay_window_expired and you resume from the oldest page instead. alert.created projection is unconditional, while trademark.* events are projected when the event projector is enabled and the mark belongs to one of the organization’s portfolios. ?portfolio_id= filters every family, alert.created included, against the portfolio membership recorded at event time — an alert on a mark outside the portfolio is not in that portfolio’s feed. occurred_at is when Signa produced the event, never the office’s own date: ingestion time for trademark.* and office_action.*, alert-creation time for alert.created. Those two direct families also carry source_date, the office-reported date at day precision (null when the feed reports none), and portfolios — the membership snapshot with your external_ref, frozen at record time. Webhook consumers should route alert-derived trademark changes on payload.data.alert.event.type; the old flat payload.data.event_type path is not part of the current envelope.

​
Telling us about it

Beta means your feedback steers what ships next. Rate limits too tight, latency that breaks a workflow, a missing recipe — email support@signa.so.