FlowRunner
PricingContact
Theme
Start Free

BitcoinApi.io

Developer Tools

BitcoinApi.io writes records onto the Bitcoin blockchain as timestamped, tamper-proof logs. Agents write log entries and JSON records on chain, read them back with proof of existence, generate wallets, and check global chain statistics.

Verified 8 actions API key available
BitcoinApi.io website Platform Documentation Capability data verified 2026-08-25
An approval completes in a process that has to be provable to somebody outside the company later
The agent assembles the evidence record: the decision, the approver, the time, and a hash of the documents rather than the documents themselves
The payload is read for anything that must never become permanently public, since a chain record cannot be redacted afterwards
Write Record is pointed at the blockchain destination explicitly, so an account that cannot notarize fails visibly instead of quietly writing to an ordinary database
The proposed record posts to the compliance channel in exactly the form it will be written
The compliance owner approves the payload before it goes on chain, because nothing on this connector and nothing on the chain can take it back

What This Integration Enables

This is not a payments integration and it has nothing to do with holding currency. BitcoinApi.io uses the chain as a notary: it writes a record and gives back timestamped evidence that the record existed when you say it did. The vendor's own framing is the useful one. An attacker who takes over a system can delete that system's log files. They cannot delete what is already on the chain. That is a genuinely different property from every other audit trail an operations team has, and it is the only reason to reach for this connector.

FlowRunner's contribution is that the evidence gets written at the moment the decision is made rather than reconstructed afterwards. An agent that routed an exception, captured an approval, and completed a payment already holds the facts and the identity of whoever approved it; publishing a fingerprint of that record is one more step in the same flow. It is also the one step in the flow that has no inverse anywhere, which is why this page's gate is where it is. Agents do the work, and the moment something becomes permanent and public belongs to a person. That is the whole of Orchestration as a Service in a single call.

Without FlowRunner

Evidence the suspect controls The audit trail for a system lives inside that system, and whoever can compromise it can also edit what it says happened
Proof that depends on a vendor The record of when something existed rests on a log retention policy and a supplier still being in business
Notarization nobody verified A write succeeds and everyone assumes it was notarized, without anything in the response confirming where it landed

With FlowRunner

Evidence outside the perimeter The proof that a record existed at a moment sits somewhere the compromised system has no authority over
Hashes on chain, content in place The document stays in its own store and only a fingerprint of it is published, which is what keeps the proof from becoming a disclosure
Destination named on purpose Every write states where it is going, so an account that cannot reach the chain refuses rather than pretending

Use Case Scenarios

  • Notarizing an approval the moment it happens

    A material approval completes inside a flow: the exception, the reviewer, the reason they gave, the time, and the version of the document they were looking at. The agent computes a hash of that document, which lives in Google Docs, and builds a compact record containing the hash, the decision, and the identifiers rather than the content. Write Record publishes it to the chain with the destination named explicitly. The returned reference is stored next to the approval in the operational database in PostgreSQL, so the internal record and the external proof point at each other.

  • A tamper evident seal over a batch, not over every event

    Publishing a record per event is neither necessary nor affordable. Instead the flow accumulates the day's processed items, computes one digest over the ordered set, and writes a single record with the digest, the count, and the window it covers. Get Logs reads the account's published entries back for the quarterly review, and the digest can be recomputed from the operational data at any time. If the two ever disagree, the operational data changed after the fact, which is precisely the thing an internal log cannot tell you about itself. A weekly summary of what was sealed posts to Slack.

  • A dispute, and the limits of what can be read back

    Months later somebody challenges when a document was agreed. The agent retrieves the chain records for that window with Get Logs and matches the hash against the archived document. Records written through this connector read back exactly as they were sent, so the comparison is direct. Records that a person wrote through the vendor's own dashboard come back encrypted, and this API has no route that decrypts them, because that key never leaves the browser. The agent says so plainly in the report rather than presenting a partial archive as complete, and the compliance owner decides whether the evidence in hand answers the question or whether the dashboard population has to be recovered another way.

Human-in-Loop Highlight

Write Record is the most irreversible operation FlowRunner can perform anywhere. There is no delete on this connector, there is no edit, and there is no delete on the chain either. Whatever is inside the payload becomes permanent and publicly readable, so a customer name, an account number, or a free text reason that happened to quote a person is not a mistake that gets cleaned up later. It gets cleaned up never. The failure runs in the other direction too: the same call can land in an ordinary database rather than on chain depending on the account behind the key, and the acknowledgement does not distinguish the two, which is how a compliance workflow succeeds for a year while notarizing nothing. So the agent does everything except the write. It builds the record, replaces documents with hashes, flags any field that looks like it carries personal data, names the destination explicitly so a plan that cannot notarize refuses rather than pretending, and posts the whole payload as it will be published: "This exact text goes on chain and is permanent and public. It contains a document hash, an approval id, and an approver's initials. Publish it?" A person reads the string and says yes. That sentence is the entire value of the integration.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

8 actions

Logs

3
  • Write Log Writes a log entry, routed to the chain or to the database according to the account's plan. The acknowledgement does not say which happened, so a flow whose purpose is proof should prefer the explicit route below.
  • Write Record Writes a record with the destination chosen explicitly, which is the operation to use when immutability is the point. Naming the blockchain destination is what makes an account that cannot notarize fail visibly instead of quietly storing something editable.
  • Get Logs Lists the log entries written under the API key, paginated. Entries written through this connector read back as they were sent; entries written through the vendor's dashboard are encrypted in the browser and cannot be decrypted through this API.

Wallet

2
  • Generate Wallet Creates the Bitcoin wallet an account writes through. A provisioning step performed once on first use, not something a flow calls per run.
  • Get Central Wallet Balance Reads the balance of the platform's own pooled wallet, which is the one the vendor broadcasts writes from. An administrator route, so most keys are refused.

Platform

3
  • Get Global Statistics Reads the platform wide account, log, and API key counters. Needs no key at all.
  • Get IP Address Reads the public IP address the request arrived from. Needs no key, which makes it a useful check of what a flow's outbound traffic looks like from outside.
  • Send Contact Message Sends a message to the BitcoinApi.io team. Needs no key.

Frequently Asked Questions

What can FlowRunner do with BitcoinApi.io?

FlowRunner agents can run Write Log, Write Record, and Get Logs in BitcoinApi.io, plus 5 more actions.

Does connecting BitcoinApi.io to FlowRunner require OAuth?

No. BitcoinApi.io connects to FlowRunner with an API key, no OAuth flow required.

Can BitcoinApi.io trigger a FlowRunner workflow automatically?

BitcoinApi.io doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with BitcoinApi.io

Free plan, no card required. Connect in minutes.