Menu
PredictionCoverageWire
InviteSign inSign up
ZettaWire/Signals API/Docs
Signals API - docs console

Developer docs for event-first signals.

Authentication, endpoint posture, schema versioning, and evidence-gated webhook rules for teams evaluating or operating the ZettaWire Signals API.

Manage keysView examples

Base

api.zettawire.com/api

Auth

X-API-Key

Schema

2026-04-22

Delivery

Polling + approved webhooks

Endpoint ledger.

Base: api.zettawire.com/apiExamples ->
Method
Path
Description
Access
GET
/api/v1/stories
List recent event-first story signals with filters for category and pagination.
Public
GET
/api/v1/stories/{story_id}
Fetch a single signal by story/event ID with canonical URL and safe preview fields.
Public
GET
/api/v1/categories
Inspect supported categories for filter builders.
Public
GET
/api/v1/trending
Evaluate high-engagement or fast-developing signals.
Starter
GET
/api/v1/stories/{story_id}/engagement
Attach social and downstream engagement context where available.
Growth
GET
/api/v1/briefings
Move from API objects into desk briefing workflows where packaged access allows it.
Growth
POST
/api/v1/webhooks
Register delivery endpoints only after webhook access is approved.
Approval

Request and response posture.

Header authJSON responses

Request

Authenticated story feed

Customer keys ride in the X-API-Key header. Account-backed keys are managed through the API keys surface.

GET
request.sh
curl -H "X-API-Key: $ZETTAWIRE_API_KEY" \
  "https://api.zettawire.com/api/v1/stories?category=security"

Response

Versioned envelope

Store the schema version with processed events and keep parsers tolerant of additive fields.

200 OK
response.json
HTTP/2 200 OK
content-type: application/json
x-ratelimit-remaining: 59

{
  "schema_version": "2026-04-22",
  "data": [
    {
      "event_id": "evt_20260422_red_sea_18431",
      "story_id": "signal-18431",
      "canonical_url": "https://zettawire.com/stories/signal-18431",
      "confirmation_status": "developing"
    }
  ]
}

Client contract.

Operational notes
Required

Authentication

Send customer keys with X-API-Key. Public evaluation stays rate-limited; paid keys are account-backed and visible in /api-keys.

Metered

Rate posture

Starter, Growth, and Enterprise packages receive separate throughput, archive, and webhook controls. Usage is metered by account and key.

Versioned

Schema safety

Current public docs target schema_version 2026-04-22. Clients should store schema_version and ignore unknown fields.

Approval

Evidence-gated webhooks

Webhook delivery requires the package entitlement plus written approval evidence. Use event_id for dedupe, verify signatures when enabled, and fall back to canonical_url for analyst handoff.

Source notes

Keep downstream systems explicit.

Signals can be early, developing, or source-limited. The payload includes posture fields so clients can decide how aggressively to automate.

  • Persist `schema_version` and `event_id` with each processed signal.
  • Use `canonical_url` when routing analysts back to human-readable context.
  • Back off on 429 responses and separate approval-gated webhook delivery from polling.
  • Do not treat `developing` or `single_source` events as fully confirmed.

Beta access

Request Signals API beta access with source attribution.

We use this form to understand developer demand, integration use cases, and which public pages produce qualified API leads.

Source tracked

Attribution

Submissions are stored through newsletter attribution today, so the growth dashboard can group leads by page, campaign, and source while we keep API-key issuance entitlement-gated.

Sourcesignals_api_docs
Page/signals-api/docs