Best architecture for syncing Make runs and approvals into Crankflo?

Questions
1

:bullseye: What is your goal?

Sync Make scenario runs and approval states into Crankflo

:thinking: What is the problem & what have you tried?

I am designing a Make integration for Crankflo and want to make it useful, not just another log stream.

The idea is to map each Make scenario to a workflow object, sync each run as proof for a task, and keep retry or approval decisions visible before triggering the next run. The interesting part is the two-way sync: Make stays great at automation, while Crankflo keeps the goal, owner, proof, memory and approval trail in one place.

What architecture would you recommend for this in Make? Should it be webhook-first with periodic API reconciliation, or mostly event-driven? Also, which fields are essential for audit and debugging: scenario id, run id, operation count, module-level error, bundle summary, execution time, owner, approval state, retry state, version of the scenario?

3

If you want to sync Make scenario runs and states, use the Make API: API Reference | Make API | Make Developer Hub

You can find all the info you need there.

Cheers,
Henk

4

I’d use webhook-first for freshness, with API reconciliation for correctness.

Have each scenario send a small status callback at started / succeeded / failed / approval-required. Crankflo should persist the raw event first and return 2xx quickly; a worker can then upsert the run. Use an idempotency key such as scenario_id + execution_id + event_type so webhook retries cannot create duplicate proof records.

I’d model approval and retry as separate command records, rather than editable fields on the run: command_id, run_id, requested_by, decision, expected_version, created_at, executed_at, result. Make should consume a command only once and return the resulting execution ID. That gives you an auditable round trip instead of just two systems overwriting each other’s state.

Then run a scheduled reconciliation from a timestamp/watermark using the Make API. Its job is only to find missed or late executions and repair state.

Minimum fields I’d keep:

  • scenario ID and scenario version
  • execution ID, correlation ID, and retry-of/parent execution ID
  • status, started/finished time, operation count
  • failed module plus error type/message
  • redacted bundle summary or payload hash (not full bundles by default)
  • owner, approval state/actor/time
  • retry count/state and last reconciled time

The important part is the failure model: reconciliation repairs missed callbacks, and idempotency neutralizes duplicate callbacks. That is more reliable than choosing either pure webhooks or pure polling.