Webhook vs Polling for Meeting Events: Why Real-Time Matters

The polling approach

Polling means repeatedly asking the API "is the meeting done yet?" on a timer:

// Check every 30 seconds
setInterval(async () => {
  const meeting = await fetch(`/v1/meetings/${meetingId}`).then(r => r.json());
  if (meeting.status === "completed") {
    await processTranscript(meeting.transcript);
    clearInterval(timer);
  }
}, 30_000);

This works, but it has problems: you're making hundreds of API calls for a meeting that might last an hour. You're paying for those requests. And you get the transcript up to 30 seconds after the meeting ends — assuming your timer fires on the right interval.

The webhook approach

Webhooks invert the relationship. Instead of your server asking "is it done?", the API calls your server the moment something happens:

app.post("/hooks/gregnote", async (req, res) => {
  const { event, transcript } = JSON.parse(req.body);
  if (event === "meeting.completed") {
    await processTranscript(transcript);
  }
  res.sendStatus(200);
});

Zero unnecessary requests. The transcript arrives seconds after the meeting ends.

When polling makes sense

For very short-lived operations — a transcription job that finishes in under a minute — polling one or two times is reasonable. The Gregnote audio transcription endpoint supports both patterns: a synchronous response for files under 25 MB, and a status endpoint for larger files when you can't receive webhooks.

What reliable webhook delivery looks like

The concern with webhooks is reliability: what happens if your server is down? Gregnote retries failed deliveries at 1 m, 5 m, 30 m, and 2 h automatically. Every attempt is logged in the dashboard with the full response body. You can replay any missed event with one click.

This makes webhooks safe to rely on for production systems — not just a developer convenience.