/ Code Examples
API Examples
Base URL: https://your-site.com/wp-json/fswa/v1
Auth header: X-FSWA-Token: <token>
1. List Failed Delivery Logs
Filter by status, webhook ID, or trigger name. Requires read scope.
curl
curl -X GET \
"https://your-site.com/wp-json/fswa/v1/logs?status=error" \
-H "X-FSWA-Token: your-token"
JavaScript — fetch
const response = await fetch(
'https://your-site.com/wp-json/fswa/v1/logs?status=error',
{
headers: { 'X-FSWA-Token': 'your-token' }
}
);
const logs = await response.json();
response — JSON
[
{
"id": 42,
"trigger_name": "woocommerce_order_created",
"status": "error",
"http_code": "503",
"response_body": "Service Unavailable",
"error_message": "HTTP 503: Service Unavailable",
"duration_ms": "2341",
"created_at": "2026-03-19 09:14:22",
"event_uuid": "d4e1f8a2-3c9b-4f1e-a7d2-8b5c1e6f9a3d",
"attempt_history": [
{ "attempt": 1, "http_code": 503, "status": "error", "attempted_at": "2026-03-19T09:14:22Z" },
{ "attempt": 2, "http_code": 503, "status": "error", "attempted_at": "2026-03-19T09:44:22Z" }
]
}
]
response_body surfaces the exact message returned by the downstream endpoint — the fastest way to identify whether the failure was a 503 outage, a 401 auth issue, or a 422 schema mismatch. attempt_history shows the full retry trail per event, including timestamps and per-attempt HTTP codes.
2. Get Delivery Stats
Aggregate success/failure counts over a time window. Requires read scope.
curl
curl -X GET \
"https://your-site.com/wp-json/fswa/v1/logs/stats?days=7" \
-H "X-FSWA-Token: your-token"
JavaScript — fetch
const stats = await fetch(
'https://your-site.com/wp-json/fswa/v1/logs/stats?days=7',
{ headers: { 'X-FSWA-Token': 'your-token' } }
).then(r => r.json());
response — JSON
{
"success": 38,
"error": 0,
"retry": 2,
"permanently_failed": 3,
"pending": 0,
"avg_duration_ms": 234,
"http_2xx": 38,
"http_4xx": 1,
"http_5xx": 4,
"total": 43
}
permanently_failed is the number to alert on. avg_duration_ms tracks endpoint latency over time — a gradual increase signals a degrading downstream service before it starts hard-failing.
3. Retry a Failed Event
Re-sends the stored payload without re-triggering the WordPress action. Requires operational scope.
curl
curl -X POST \
"https://your-site.com/wp-json/fswa/v1/logs/42/retry" \
-H "X-FSWA-Token: your-token"
JavaScript — fetch
const logId = 42;
const result = await fetch(
`https://your-site.com/wp-json/fswa/v1/logs/${logId}/retry`,
{
method: 'POST',
headers: { 'X-FSWA-Token': 'your-token' }
}
).then(r => r.json());
response — JSON
{ "success": true, "job_id": 74 }
job_id is the queue entry for this retry. Use it to correlate with GET /queue/stats output when debugging whether the job was picked up by the dispatcher.
4. Bulk Retry Multiple Failed Events
Recover a batch of failures at once. Requires operational scope.
curl
curl -X POST \
"https://your-site.com/wp-json/fswa/v1/logs/bulk-retry" \
-H "X-FSWA-Token: your-token" \
-H "Content-Type: application/json" \
-d '{"ids": [42, 43, 44]}'
JavaScript — fetch
await fetch(
'https://your-site.com/wp-json/fswa/v1/logs/bulk-retry',
{
method: 'POST',
headers: {
'X-FSWA-Token': 'your-token',
'Content-Type': 'application/json'
},
body: JSON.stringify({ ids: [42, 43, 44] })
}
);
response — JSON
{ "retried": 3, "skipped": 0 }
skipped counts IDs that were not in a retriable state — already pending, processing, or succeeded. Non-zero means your ID set included events that didn't need recovery. Check this in automated scripts to detect stale IDs.
5. Replay a Successful Event
Resend a previously delivered event. Carries the original X-Event-ID for deduplication. Requires operational scope.
curl
curl -X POST \
"https://your-site.com/wp-json/fswa/v1/logs/17/replay" \
-H "X-FSWA-Token: your-token"
JavaScript — fetch
const logId = 17;
await fetch(
`https://your-site.com/wp-json/fswa/v1/logs/${logId}/replay`,
{
method: 'POST',
headers: { 'X-FSWA-Token': 'your-token' }
}
);
6. Queue Stats & Health
Poll queue depth and system health from a monitoring system or uptime dashboard. Requires read scope.
curl — queue stats
curl -X GET \
"https://your-site.com/wp-json/fswa/v1/queue/stats" \
-H "X-FSWA-Token: your-token"
curl — system health overview
curl -X GET \
"https://your-site.com/wp-json/fswa/v1/health" \
-H "X-FSWA-Token: your-token"
response — JSON (/health)
{
"success_rate": 89,
"webhooks": { "total": 4, "active": 4 },
"logs": {
"total": 43,
"success": 38,
"permanently_failed": 3,
"retry": 2
},
"queue": {
"pending": 2,
"processing": 0,
"permanently_failed": 3,
"due_now": 2
},
"velocity": {
"last_hour": 12,
"last_day": 43,
"avg_duration_ms": 234
},
"observability": {
"avg_attempts_per_event": 1.4,
"queue_stuck": false,
"wp_cron_only": false
}
}
queue.due_now is the most actionable field for alerting — non-zero means jobs are overdue and WP-Cron may not be running. observability.queue_stuck flags this explicitly. velocity.last_hour and avg_duration_ms feed directly into dashboard panels without additional aggregation.
7. Toggle a Webhook On / Off
Disable during deployments or incidents. Re-enable without touching wp-admin. Requires operational scope.
curl
curl -X POST \
"https://your-site.com/wp-json/fswa/v1/webhooks/3/toggle" \
-H "X-FSWA-Token: your-token"
JavaScript — fetch
const webhookId = 3;
await fetch(
`https://your-site.com/wp-json/fswa/v1/webhooks/${webhookId}/toggle`,
{
method: 'POST',
headers: { 'X-FSWA-Token': 'your-token' }
}
);
response — JSON
{
"id": 3,
"name": "Order sync — HubSpot",
"endpoint_url": "https://hooks.example.com/wp/order",
"is_enabled": false,
"updated_at": "2026-03-19 14:22:11"
}
Returns the full updated webhook state. Always check is_enabled in your script rather than assuming the toggle succeeded — this is the confirmation.
