This guide shows how to take darwintIQ API output and forward it into other systems such as alerting tools, chat apps, automation platforms, or your own services.

What This Integration Is For

Webhook-based workflows are useful when you want to:

trigger downstream automations when new events appear
create review tasks for analysts or traders
pass darwintIQ output into custom bots or middleware

Important Limitation

The darwintIQ API does not push events directly to your webhook endpoint. Instead, your system must poll the API, detect relevant changes, and then send the webhook payload to your destination.

In practice, this means:

Your service fetches data from darwintIQ.
Your service checks whether something new happened.
Your service forwards the relevant payload to your webhook target.

Minimum Setup

Choose the darwintIQ endpoint to monitor.
Store a valid API token in your integration service.
Poll the API on a controlled schedule.
Detect new or changed events.
Send a webhook request to your target system.
Log delivery results and failures.

Common Use Cases

Entry to Alert Bot

Use a small service to monitor recent model or signal changes and forward them to tools such as Telegram or Discord.

Typical payload elements:

symbol
model identifier
entry type
fitness
entry move context
timestamp

Entry to Task System

Create tasks in tools such as Notion, Trello, or similar systems whenever a new event appears.

Typical use cases:

analyst review queues
backtest follow-up tasks
manual validation workflows

Entry to Custom Bot

Forward filtered darwintIQ data to your own execution bot, simulation engine, or decision layer.

This is usually best treated as a gated workflow, where the bot validates the signal before acting on it.

How the Integration Works

A typical webhook pipeline looks like this:

Poll an endpoint such as /v1/models?symbol=EURUSD&sort=latest.
Parse the response and extract the latest relevant item.
Compare it with the last processed event.
If it is new, build a webhook payload.
POST that payload to your destination endpoint.
Store the event identifier so it is not sent again.

Duplicate Event Protection

A reliable webhook integration should always suppress duplicate sends.

At minimum, store enough information to identify the last processed event, such as:

model ID
event timestamp
symbol
entry type

Without this, polling can easily cause repeated notifications for the same underlying event.

Troubleshooting

If the webhook workflow does not behave as expected, check the following first:

repeated alerts You are likely not storing and comparing the last processed event correctly.
no alerts sent The polling service may not be running, the webhook target may be unreachable, or the filter rules may be too strict.
HTTP 401 from darwintIQ Your API token is missing, invalid, or expired.
webhook delivery failures The destination service may reject the payload, rate limit the requests, or require a different schema.
noisy signals Add stronger filtering so every minor change does not trigger a downstream action.

Production Guidance

Before using webhook workflows in production:

add rate limiting and retry logic
use idempotency or duplicate suppression
log every outbound delivery attempt
protect secrets and webhook URLs
add fallback handling when the destination system is unavailable

Example Workflow

A simple implementation can be built as a scheduled job, serverless function, or lightweight backend service that:

fetches https://api.darwintiq.com/v1/models?symbol=EURUSD&sort=latest
checks whether a new relevant event exists
forwards the event to your webhook target

Example Request

GET https://api.darwintiq.com/v1/models?symbol=EURUSD&sort=latest
Authorization: Bearer YOUR_TOKEN

Useful starting points include:

/v1/models
/v1/supres
/v1/trendmatrix

Repository

Public example code is available here:

https://github.com/darwintIQ/API

Webhook use cases