Market signals.
Meet your next integration.

1 Authenticate and create an alert

Request an API key from support@stocklet.app. Set STOCKLET_API_KEY in your server environment, then send your first request.

The response contains data.id. Use this ID to retrieve the alert or connect it to a webhook.

{
  "data": {
    "id": "alt_breaking_news_01",
    "type": "breaking_news",
    "ticker": "AAPL",
    "enabled": true,
    "conditions": {},
    "created_at": "2026-11-08T14:30:00Z"
  }
}

2 Retrieve your existing alerts

List alerts for a ticker or fetch a single rule by its ID. This retrieves saved configuration; it does not return news stories.

3 Connect your webhook

Register a public HTTPS endpoint and subscribe to your alert. The creation response includes a signing secret; store it securely.

When a matching story is processed, Stocklet sends the event payload to your endpoint. Verify its signature before processing.

Use a server-side API key in the Authorization header. The key determines the account that owns your alerts and webhook registrations.

Missing or invalid keys return 401. Requests outside your access permissions return 403.

Keep keys in environment variables. Never embed them in frontend code, URLs, or public repositories. Contact support to provision or replace a key.

Requests and responses use JSON with snake_case fields. Timestamps are ISO 8601 UTC strings. IDs are opaque strings; preserve them exactly.

Single-resource responses use { "data": { ... } }. Lists are newest first and include next_cursor; null means the last page. Tied timestamps are ordered by ID.

Use limit and cursor for pagination. A cursor belongs to its original filters. An invalid cursor returns 400.

Creation returns 201, reads and updates return 200, and successful deletion returns 204 without a response body.

An alert is an account-owned rule for one ticker. Create it through its type-specific endpoint, then retrieve, update, pause, or delete it.

GET /alerts returns saved alerts across types. Filter by the singular type identifier, ticker, or enabled state. To retrieve actual matching events, use your alert event history.

Your price level. Your percentage move. A signal when the condition is met.

Conditions

Use mode target_price with direction above or below and a positive value in the listing currency. Or use mode percent_change with direction up or down, a positive percentage value, and window day (relative to the previous trading close). Price rules trigger once and become disabled; re-enable to arm them again.

{
  "mode": "target_price",
  "direction": "above",
  "value": 250
}

All operations require Bearer authentication. Missing alerts and alerts from another account return 404. Invalid request fields return 400.

Follow publicly disclosed buying, selling, and option exercises.

Conditions

Optional transactions filter: purchase, sale, or option_exercise. Omit it to follow all supported disclosed transactions. Events describe processed public disclosures, not the time a trade was executed.

{
  "transactions": [
    "purchase",
    "sale"
  ]
}

All operations require Bearer authentication. Missing alerts and alerts from another account return 404. Invalid request fields return 400.

Keep earnings releases, conference calls, and transcripts in view.

Conditions

Optional events filter: release, call, or transcript. Omit it to receive all three. A call event announces available call information; it is not a configurable reminder.

{
  "events": [
    "release",
    "call",
    "transcript"
  ]
}

All operations require Bearer authentication. Missing alerts and alerts from another account return 404. Invalid request fields return 400.

Official company announcements, delivered as structured events.

Conditions

No additional conditions required. An enabled alert follows supported official press releases for its ticker.

{}

All operations require Bearer authentication. Missing alerts and alerts from another account return 404. Invalid request fields return 400.

Stay close to the stories that matter to the stocks you follow.

Conditions

No additional conditions required. An enabled alert follows supported breaking news associated with its ticker.

{}

All operations require Bearer authentication. Missing alerts and alerts from another account return 404. Invalid request fields return 400.

Track upgrades, downgrades, initiations, and price target changes.

Conditions

Optional actions filter: upgrade, downgrade, initiation, or price_target_change. Omit it to follow all supported analyst actions.

{
  "actions": [
    "upgrade",
    "downgrade",
    "initiation",
    "price_target_change"
  ]
}

All operations require Bearer authentication. Missing alerts and alerts from another account return 404. Invalid request fields return 400.

The same event ID identifies an event in feeds, alert history, and webhook messages. A feed event has no alert_id.

Retrieve historical matches for your account’s own alerts, including price rules. The optional type, ticker, and alert_id filters combine with the feed time and pagination parameters.

Each result includes its matching alert_id. One event can match several alerts; deduplicate a match by the pair (id, alert_id).

Deleting an alert stops future matching but does not remove existing event history.

The signing secret is included only in the creation response. Store it immediately. List and retrieve responses never expose it. To replace a secret, create a new webhook and retire the old one.

PATCH accepts URL, filters, and enabled state. Arrays replace their previous values; alert_ids: null clears the ID filter. Disabling or deleting a webhook cancels pending retries.

Every alert type uses the same envelope. The type-specific data lives inside data. Select a type to inspect its full incoming message.

Each delivery includes a Unix timestamp in seconds and a versioned HMAC-SHA256 signature. Use the signing secret returned when creating your webhook.

Content-Type: application/json
Stocklet-Timestamp: 1794148200
Stocklet-Signature: v1=<64-character lowercase hex>

Signing input

Compute HMAC-SHA256 over the timestamp, a literal period, and the exact raw request bytes: timestamp + "." + raw_body.

Compare signatures in constant time. Reject timestamps more than five minutes from your server clock. Do not parse and re-serialize the JSON before verification.

Timestamp and signature are regenerated for every retry; event IDs stay unchanged. The sample timestamp is illustrative.

After verification, persist or enqueue the event and return any 2xx response within ten seconds. Process the event asynchronously.

• Network failures, timeouts, and non-2xx responses trigger retries with increasing delays for up to 24 hours.
• Delivery order is not guaranteed. Duplicate messages can occur.
• Deduplicate event processing by id. If each alert match needs separate handling, use (id, alert_id).
• Alerts created or re-enabled later do not replay historical events. Use GET endpoints to retrieve available history.
• Successful webhook registration does not test your receiver. Verify it in your own environment before depending on deliveries.