Zapier and Make

BitGraph as a step in an ordinary business workflow. A file arrives somewhere, it gets recorded, and the proof goes wherever the rest of your process needs it. No code, and the same ledger the API and MCP write to.

Where the step goes
Google Drive  ->  Create BitGraph  ->  Google Drive   (write the proof URL back)
DocuSign      ->  Create BitGraph  ->  Salesforce     (attach it to the record)
Dropbox       ->  Create BitGraph  ->  Slack          (post the causal window)
Any file      ->  Verify BitGraph  ->  Filter         (branch on verified)

Three steps

  • • Create BitGraph · Give it a file. It returns the proof, its causal position, and a link to the proof page. A file already on record comes back with its existing proof rather than being recorded twice.
  • • Verify BitGraph · Give it a file, or a proof, or both. It returns verified or not, and says separately whether the file itself was checked against the proof.
  • • Retrieve Proof · Look up an existing proof by file, digest, or BitGraph number, including the Ethereum anchor window.

The file never leaves your automation

Both platforms hash the file themselves and send only the 32-byte SHA-256 digest. Zapier and Make hold your file already, since they are what fetched it from Drive or Dropbox, but it goes no further: BitGraph receives a hash and nothing else. This is also why there is no field anywhere for a file URL that BitGraph would fetch itself.

Zapier

The three steps above are built as ordinary Zapier actions. Map a file into Create BitGraph and every field of the proof is available to later steps: the hash, the counter, the epoch, the chain, the proof URL, and the two Ethereum block times that bracket the recording.

Add BitGraph to your Zapier account

The source is in packages/zapier/ in the repository.

Make

Make does this with its built-in HTTP and Tools modules, with nothing to install. It works because Make's own sha256 emits base64 of the raw digest, which is exactly the form the API takes:

Make expression
{{sha256(2.data; "base64")}}

Put that in the body of an HTTP module pointed at the commit endpoint:

HTTP module, request content
POST https://bitgraph.ing/api/commit

{
  "digests": [{ "digestB64": "{{sha256(2.data; \"base64\")}}", "hashAlg": "sha256" }],
  "chainId": "bitgraph:main"
}

Exact module settings for all three operations, the URL-safe digest expression the proof links need, and importable scenario blueprints are in packages/make/ in the repository.

Reading the result

Two output fields deserve a second look, because acting on the wrong reading of either is the mistake worth avoiding.

  • • artifactBinding is reported separately from verified, because “this proof is genuine” and “this file is the one the proof describes” are different claims. checked means the file was hashed and matches. not-checked means the proof is sound but nothing tied it to a file. mismatch means the proof is genuine and is for different bytes.
  • • bitgraphedAfter and bitgraphedBefore are the two Ethereum blocks that bracket the recording. A proof carries no clock reading of its own, so this pair is the time statement, and it is a window rather than an instant.

A freshly created proof has the lower bound but not yet the upper one: the later anchor lands with the next Ethereum block BitGraph anchors to, usually within a minute. If a step posts a time somewhere, either say “after” and use the lower bound, or wait and run Retrieve Proof for the settled window.

Notes

  • • Re-running is safe. A file already on record comes back with its existing proof and nothing new is created. Recording the same bytes again is a deliberate choice, because a second recording is a second causal position and means something different from the first.
  • • Recordings are permanent. The ledger has 10-year retention and no deletes. Point these steps at files you mean to put on record.
  • • Two failures are not failures. A 503 during the daily epoch rotation and a 429 from the rate limiter both reject before anything is minted, so both are safe to retry. Zapier retries by itself; in Make, use an error handler with Retry.
  • • One ledger. A recording made by a Zap is indistinguishable from one made by dropping the file on the site, and shows up on the same Roll.
  • • Verification does not require us. Every proof these steps return can be checked offline with @mikeargento/bitgraph-verify, without this site or any network. See Verification.