Webhooks and Integrations
Honest take on what's wired up for outbound integration today, what's on the roadmap, and which workarounds get you most of the way.
What ships today
Outbound webhooks (Nyquest -> your URL): NOT BUILT. There is currently no way to register a URL and have Nyquest POST to it when an event happens. No "agent run completed" callback, no "wallet funded" notification, no "low balance" alert push.
Inbound webhooks (your service -> Nyquest): the only one is the Stripe billing webhook at POST /billing/webhook, which Stripe itself calls when a payment lands. This is internal infrastructure, not a user-facing feature — you can't repurpose it for your own integrations.
MCP server interface: the Nyquest backend does NOT expose itself as an MCP server. You can't point Claude Desktop or another MCP host at api.nyquest.ai and have it auto-discover Nyquest's tools.
That's the honest state. The platform's primary integration surface is the REST API, full stop.
What's in flight (roadmap)
| Feature | Status |
|---|---|
| Outbound webhooks (configurable per event type) | Roadmap, no ETA |
| MCP server interface for Nyquest backend | Roadmap, no ETA |
| Per-PAT scoping (read-only / endpoint-restricted) | Roadmap |
Embedding endpoint (POST /v1/embeddings) | Roadmap |
| Public events API (long-poll or websocket for in-progress runs) | Roadmap |
If any of these matter for your use case, talk to a real human. User demand drives the priority order.
Workarounds that work today
"I want to know when my agent run finishes"
There is no way to attach to a run that has already started — starting the run is the stream. POST /v1/agents/run responds with an SSE stream that stays open for the life of the run, so start the run from the process that wants the completion signal, and read that stream to its terminal event:
const response = await fetch('https://api.nyquest.ai/v1/agents/run', {
method: 'POST',
headers: {
Authorization: 'Bearer ' + pat,
'Content-Type': 'application/json',
},
body: JSON.stringify(runRequest), // the same body you'd use to start any run
})
const reader = response.body.getReader()
const decoder = new TextDecoder()
let buffer = ''
const TERMINAL = ['final', 'error', 'stopped']
while (true) {
const { done, value } = await reader.read()
if (done) break
buffer += decoder.decode(value, { stream: true })
let idx
while ((idx = buffer.indexOf('\n\n')) !== -1) {
const evt = buffer.slice(0, idx)
buffer = buffer.slice(idx + 2)
if (evt.startsWith('data: ')) {
const payload = JSON.parse(evt.slice(6))
if (TERMINAL.includes(payload.type)) {
// Run is over -- fire your callback here
onComplete(payload)
}
}
}
}A run ends on any of three event types — final, error or stopped — so treat all three as terminal. Waiting for a completed event hangs forever: there isn't one.
Same pattern as a webhook callback would have, but you initiate the connection instead of receiving one. If the connection drops you can't reattach to that run; poll GET /v1/agents/runs for its final status instead.
"I want to call Nyquest from a Claude Desktop / Cursor / other MCP host"
Two options:
-
Use Nyquest as an OpenAI-compatible backend. Most MCP-aware tools also support OpenAI-compatible APIs. Point them at
https://api.nyquest.ai/v1with your PAT. You get chat completions; you don't get tool-calling-as-MCP, but most MCP hosts still work because they can fall back to OpenAI-style function calling. -
Wrap Nyquest in a thin MCP server. Write a small MCP server that implements MCP tools mapped to Nyquest endpoints (
chat,agent_run, etc.). This is a few-hour project for someone familiar with MCP. We don't ship one but the model is straightforward.
"I want notifications when something changes in my account"
Poll. GET /user/me for tier changes, GET /billing/account for balance, GET /v1/agents/runs?limit=5 for recent runs. Hourly polling is cheap and rate-limit-friendly.
"I want to integrate with Slack / email / etc."
Right now, your workflow is:
- Nyquest API call → response in your code
- Your code → Slack/email/etc.
Your code is the integration glue. There's no Nyquest-managed connector store yet. If you want platform-side connectors to common SaaS, talk to a real human — it's on the roadmap as L3 agent tools.
"I want to listen for low-balance warnings"
Poll GET /billing/account every few minutes. When wallet_balance_micros / 1_000_000 drops below your threshold, fire your own alert.
The dashboard shows a low-balance toast at <$1.00; that's frontend-only and doesn't push anywhere.
External integrations that DO work
Even without first-party webhooks/MCP, these patterns work today:
As a backend for a custom UI
You build the UI, you call Nyquest's API. You get all platform features (memory, BYOK, models). Most "build a custom AI app" use cases fit here.
Via OpenAI-SDK clients
The /v1/chat/completions endpoint is OpenAI-compatible. Any tool that targets OpenAI-compatible APIs can target Nyquest by changing the base URL and PAT. See OpenAI Compatibility.
CI/CD prompt evaluation
Run scripted prompts in CI to check model behavior across versions:
# .github/workflows/eval.yml
- run: |
curl https://api.nyquest.ai/v1/chat/completions \
-H "Authorization: Bearer ${{ secrets.NYQUEST_PAT }}" \
-H "Content-Type: application/json" \
-d @prompts/eval.json \
| tee result.json
test "$(jq -r .choices[0].finish_reason result.json)" = "stop"Server-side batch via a worker queue
If you have batch needs (e.g. translate 10,000 strings), run a worker that drains a queue, calls /v1/chat/completions, writes results. Use exponential backoff on 429. Stay under the 120/min limit (Pro) and you can do ~7,200 requests/hour comfortably.
Why no webhooks yet
Quick context on the design choice: webhooks add operational complexity (retry logic, signature verification, dead-letter handling, customer-side endpoint reliability). The team chose to ship a clean SSE stream + polling-friendly endpoints first, observe what users actually want, then add webhooks once the request pattern is clear.
If you're blocked on this, your feedback shapes the priority. Talk to a real human.
Where to next
- API Overview — what the API does and doesn't include
- OpenAI Compatibility — drop-in usage
- Endpoints Reference — full endpoint catalog
- Personal API Keys — token management
- Rate Limits and Quotas — what limits apply