Skip to main content
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

ApproachBest for
WebhooksProduction services that need to react to results in real time. Your server receives a push — no loop required.
PollingScripts, 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.