Skip to main content

Signaliz REST API reference

Endpoints, authentication, request shapes, versions, and response behavior.

Written by Josh Whitfield

Signaliz REST API reference

All public product calls use HTTPS, JSON, and a Signaliz API key.

Server: https://api.signaliz.com
Base:   /functions/v1/api/v1
Auth:   Authorization: Bearer YOUR_SIGNALIZ_API_KEY

Product endpoints

Product

POST path

Company Signal Enrichment

/company-signals

Signals First

/signals-first

Signal to Copy

/signal-to-copy

Signal Awareness

/signal-awareness and its /signals and /companies/* actions

/signals remains a compatibility alias for Signals First. Equivalent version 2 request and response schemas are available by replacing /api/v1/ with /api/v2/.

Example: Signals First

curl -sS https://api.signaliz.com/functions/v1/api/v1/signals-first \
  -H "Authorization: Bearer $SIGNALIZ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"companies that announced an AI partnership","limit":25}'

Response rules

  • Non-2xx responses are failures; inspect the error code and retry guidance.

  • A result count is never guaranteed when evidence is insufficient.

  • Save run IDs, job IDs, and idempotency keys before handing work to another process.

  • Reuse an idempotency key for the same logical request after an ambiguous network failure.

  • Do not treat a transport-level 200 as success when the payload says success: false, ok: false, or contains a terminal failure.

For the exact current schemas and examples, open Settings → Connect → API reference or download Signaliz's OpenAPI document.

Did this answer your question?