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
v1.1; sending them to create or update returns 400. If you need
batching today, do it on your side: dedupe by webhook-id and roll alerts
up on your own schedule.
Replay: forward-only
POST /v1/watches/{id}/replay
re-evaluates from the next ingestion sync forward. The from_date
parameter (historical replay against a chosen date) is reserved for v1.1 —
sending it returns 400. Replay also requires the watches:admin scope,
which is granted on request via support@signa.so.
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:
class,mark, andownerpreviews complete in a few seconds.similaritypreviews 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 apreview_timeout504(retryable: false— narrow the query), and concurrent previews429with aRetry-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 edge5xx during a deploy or an edge block) does not appear there — and
edge-served 502/503 bodies carry a fixed sentinel request_id
(req_edge_static_502 / req_edge_static_503) 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. (Edge-generated 4xx errors carry a synthetic id:
most blocks — WAF 400/403, oversized payloads/URIs — carry a
req_edge_* id you can quote, but the edge rate-limit 429 carries the
req_unknown sentinel, which is not traceable — include the
x-amz-cf-id header and timestamp for those too.) 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 payload field rename in progress
Thealert.created payload carries the matched trademark under both
trademark_id (canonical — matches the REST Alert resource) and
trademark_record_id (deprecated alias, removed in v1.1). New
consumers should read trademark_id.