Sixtyfour’s async endpoints accept an optional webhook_url parameter. When a job finishes, Sixtyfour sends a POST request with the results to that URL. This eliminates the need to poll /job-status/{task_id} and is the recommended approach for production integrations.
When to Use Webhooks vs Polling
| Approach | Best for |
|---|
| Webhooks | Production services that need to react to results in real time. Your server receives a push — no loop required. |
| Polling | Scripts, notebooks, and environments that cannot receive inbound HTTP requests. |
If your infrastructure supports inbound HTTPS, use webhooks. If not — or if you are prototyping locally — polling works fine as a fallback.
End-to-End Flow
A webhook integration has two sides: the request (you call Sixtyfour) and the handler (Sixtyfour calls you).
Step 1: Send an async request with webhook_url
Include webhook_url in the body of any supported async endpoint.
curl -X POST https://api.sixtyfour.ai/find-email-async \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"lead": {
"name": "Jane Smith",
"company": "Northgate Labs",
"linkedin_url": "https://linkedin.com/in/janesmith"
},
"webhook_url": "https://your-server.com/webhooks/sixtyfour"
}'
The response returns a task_id. Store it — you will use it to match the incoming webhook payload.
{
"task_id": "550e8400-e29b-41d4-a716-446655440000"
}
Step 2: Handle the webhook
When the job completes, Sixtyfour POSTs the result to your webhook_url. Your handler must return a 2xx status code within 10 seconds. See the Webhooks reference for Flask and Express handler examples.
Return 2xx even for unknown task_id values. Returning a non-2xx triggers retries, which wastes delivery attempts.
Testing Locally
Your local development server is not reachable from the internet. Use a tunneling tool to expose it:
# ngrok
ngrok http 3000
# Then use the generated URL as your webhook_url:
# https://abc123.ngrok-free.app/webhooks/sixtyfour
Other options include Cloudflare Tunnel and localtunnel. Use the HTTPS URL from your tunnel as the webhook_url value.
Production Checklist
Review the best practices and retry behavior in the Webhooks reference. Key additions for production:
- Track your tasks. Store the
task_id from each async request. Validate incoming webhooks against your stored set to ignore unexpected payloads.
- Monitor delivery. If all 5 retry attempts fail, the webhook is marked as undelivered. Results remain available via
GET /job-status/{task_id} as a fallback.