All documentation

Reading results

Getting confirmation outcomes back into your system while webhooks are pending.

Polling is the only option today

There is no push channel yet, so outcomes have to be pulled. From your own server that means reading the orders table over the Data API with an access token. Filter on the ids you are waiting for rather than listing the table, and select only the columns you need.

Suggested loop

  1. 1Keep the ids of orders still in pending, processing, or calling.
  2. 2Ask for that batch in one request with an in filter, on an interval matched to your call volume, not per second.
  3. 3On a terminal status, drop that id from the batch and write the outcome to your own record.
  4. 4Give up after a ceiling you choose. postponed orders can stay open for a long time.

Polling a batch

cURL
curl "https://nvkkanirwnjjvuwxsjch.supabase.co/rest/v1/orders?select=id,status&id=in.(3f1c...,7a20...)" \
  -H "apikey: $PUBLISHABLE_KEY" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Accept-Profile: public"

The outcome table in calls_history carries the reason a call did not confirm, keyed by operation, when the status alone is not enough.

Cost signal

The credits table is the workspace balance, which belongs to the owner and is shared across every member. Read it on a schedule and alert your team before a batch stalls: an empty balance stops agents from picking up new work.