Document Workflow Webhooks: Send File Data to Your API

TL;DR: A document workflow webhook sends file details, plus any values the workflow read out of the document, to a URL you own. In The Drive AI the step is called Send to Another App: you give it a URL, a method of POST, PUT, or PATCH, and either no key, a Bearer token, or an API key header. It sends a standard payload of file details by default, or a JSON body you write yourself, which is how an extracted vendor and total reach your accounting system as fields rather than as a filename to parse.

Every evaluation of a document tool reaches the same question. Someone from engineering asks whether it can talk to the system you already run: the ERP, the practice management database, the internal service nobody outside the team has heard of.

The honest answer is rarely a named integration. It is a webhook. One step makes an HTTP request to an address you control, carrying what the workflow knows about the file, and your side decides what that means.

A document workflow webhook is an outbound HTTP request sent by a step in a document workflow, carrying details about a file and the data read from it, to a URL the receiving system owns.

What is a webhook, and what should it carry?

A webhook is a reverse API call. Instead of your system polling ours asking whether anything happened, our system calls a URL you publish the moment something does, with a body describing the event. You write the endpoint once, and the delay collapses from a polling interval to a single request.

What the body carries is the choice that matters, and there are two answers. An event notification says only that something happened: file 12ab was filed, come and look. It is small and it survives schema changes, but the receiver must make a second call to learn anything useful, which means credentials pointing back and a way to resolve an identifier.

A data push carries the payload: the vendor, the total, the due date, the folder it landed in. The receiver acts immediately with no callback. The cost is that the body holds real data, so the transport and the endpoint have to be treated accordingly. For document workflows the data push is almost always right, because the point of reading a document is to produce values, and a notification throws them away.

Why an outbound webhook often beats a connector platform

If you own the receiving system, a webhook is fewer moving parts than a connector platform, and the running cost does not scale with volume.

Connector platforms earn their keep when neither end is yours: two SaaS products with fixed APIs and glue in the middle that operations can maintain without writing code. They do that job well.

The calculation changes when the destination is your own service. A connector platform adds a third party to the path, another account to secure, another vendor to review, and a per task price that grows with every document you process. What you get back is a drag and drop editor for a mapping you could write in a handful of lines on your own endpoint. A direct call also fails in one place, so when something breaks you read one log on a server you already monitor.

The trade is real. Connector platforms bring queueing, retries, and a UI for non engineers. If nobody on your team owns an HTTP endpoint, take the connector.

What should a receiving endpoint do?

A good endpoint accepts fast, verifies the caller, treats the payload as untrusted input, and does the same thing twice without doubling the effect.

Respond quickly. Accept the request, write the body to a queue, and return 202. Do not do the ledger write, the PDF fetch, and the email inside the request. Senders have timeouts, and slow endpoints turn load into lost events.

Be idempotent. Assume you will receive the same event more than once, because retries, replays, and reruns all exist. Derive a key from the payload, a file identifier plus an invoice number is usually enough, and make a repeat arrival a no op rather than a second invoice.

Verify the caller. The URL alone is not a secret; it lands in logs, proxies, and screenshots. Require a credential on every request, compare it in constant time, reject anything without one, and serve HTTPS only.

Do not trust the payload. Values read out of a document are user supplied data, and a scanned PDF is attacker controlled if anyone can email one in. Validate against a schema, cap the body size, parameterize every query, never interpolate a value into a shell command or into HTML, and reject an amount you cannot parse.

Log the raw body. When a field arrives wrong, that argument takes seconds to settle if you kept what was sent, and a day if you kept only what you parsed.

How does Send to Another App work?

Send to Another App is the webhook step. It posts either the standard file details payload or a JSON body you write. Three settings are the whole configuration:

• URL: the endpoint you want called.
• Method: POST, PUT, or PATCH.
• Authentication: No key needed, Bearer token sent as an Authorization: Bearer … header, or API key sent as an X-API-Key header.

By default it sends a standard payload of file details, which is enough when your service only needs to know a file exists.

The version worth building writes its own body. Put a Read Details from File step before the webhook and name the fields you want: vendor, invoice number, total, due date. Those named values become available to later steps, and the webhook body is where they earn their keep.

You do not type the variables. The panel shows the values available at that point in the workflow, and clicking one inserts it. That matters more than it sounds, because what is available depends on the source: an email source can offer the sender and the subject, a chat source offers the channel and who shared the file, and a folder name is only offered where the source can actually fill one. A workflow is refused at save if it references a value its source cannot provide, so the panel only ever offers you what will resolve.

Source values are spelled plainly, such as {{trigger.file.name}}, {{trigger.sourceName}}, and, on an email source, {{trigger.sender}} and {{trigger.subject}}. A value read out of the document points at the step that read it and the field you named there, which is why you insert it by clicking rather than guessing at it.

{
  "event": "invoice_approved",
  "source": "{{trigger.sourceName}}",
  "file_name": "{{trigger.file.name}}",
  "received_from": "{{trigger.sender}}",
  "vendor": "{{nodes.extract_1.entities.vendor}}",
  "invoice_number": "{{nodes.extract_1.entities.invoice number}}",
  "total": "{{nodes.extract_1.entities.total}}",
  "due_date": "{{nodes.extract_1.entities.due date}}"
}

Field names may contain spaces, so the values you named read the way you wrote them.

That body is the difference between an integration and a chore. Your system receives fields it can write straight to a row. It does not receive INV-4471 Pinecone.pdf and a regular expression to maintain. The extraction side is covered in extracting data from documents without templates.

The step carries the external cost badge, which is how the canvas marks anything that contacts a service outside The Drive AI. If a person just needs to know something happened, Send a Message is simpler: it sends to Slack or to an email address. It does not send to Microsoft Teams.

Example workflows

Each of these is one sentence typed into the builder. The steps appear on a canvas afterwards, and every one can be edited.

When an invoice arrives by email from @pinecone.com, get the vendor, invoice number, total, and due date, ask Dana to approve anything over $5,000, file it under Vendors/Pinecone Systems/2026, and post the fields to our accounting API.

When a signed contract is filed in Clients/Northwind/Contracts, check whether it is fully signed, get the counterparty, effective date, and term, and send those to our practice management system.

When a new lease lands in the Leases folder, get the tenant name, unit, rent, and start date, and if the rent is over $3,000 ask Priya first, then move it to Properties/Riverside/Leases/2026 and post it to our property management API.

The first uses Gmail or Outlook attachments as the source, so {{trigger.sender}} is available to the body, and its approval step pauses the run: nothing downstream, webhook included, fires until someone decides, so your ledger never sees an unapproved invoice. The same shape works over a SharePoint document library, where files are renamed and moved in place and the webhook calls an internal indexing service instead of an accounting one.

Webhook vs Zapier vs Power Automate

All three get file data into another system. They differ in what triggers them, what they see inside a document, and who maintains the middle.

So: Zapier and Make for two products you do not control, Power Automate when the receiver is Microsoft 365 and the columns are reliably filled, a workflow webhook when the destination is yours and the decision depends on what the document says.

What a document workflow webhook will not do

It sends file details, not files, and it is one outbound step rather than a platform. The limits:

• It sends details about a file. Plan for a payload of fields, not a file transfer.
• It is outbound only. There is no inbound endpoint that starts a workflow from your side.
• No named app integrations sit behind it. No catalogue, no per app auth screens. Just the URL you give it, one of three methods, and one of three authentication choices.
• It carries the external cost badge, because it contacts a service outside The Drive AI.
• The steps before it can be wrong. Read Details from File and Ask AI About the File read the document with AI, which costs a little per file and can occasionally be wrong. If the value drives money, put Ask a Person to Approve in front.
• Approvals expire. The wait is 24 hours, 3 days, or 1 week, after which the file takes the Expired exit.
• Plan requirement. Workflows on files uploaded to The Drive AI work on every plan. Connecting Gmail, Outlook, Slack, Teams, Google Drive, OneDrive, SharePoint, or Dropbox needs the Max plan on a personal workspace, or any Team plan.

Every run is recorded in an activity feed, can be replayed on the canvas exactly as it happened, and retried from the step that failed. When your endpoint was down, you rerun from the webhook step rather than reprocessing the document.

Setting it up

1. Build the endpoint first. Accept POST, require a credential, return 202, and log the raw body. A handler that stores the payload is enough to start.
2. Describe the workflow in plain English, including the part about posting to your system. The steps appear on the canvas.
3. Check the Read Details from File step before the webhook, and name every field your endpoint expects. Those names are the values you can insert later.
4. Open Send to Another App, paste the URL, pick POST, PUT, or PATCH, and choose Bearer token or API key. Leave the standard payload on for the first run.
5. Run one real file, read what arrived in your log, then switch to a custom JSON body mapped to the shape your API wants.
6. Add Ask a Person to Approve upstream if the call has financial consequences, then watch the first week in the activity feed.

Frequently Asked Questions

What is a document workflow webhook?

It is an outbound HTTP request made by a step inside a document workflow. When a file reaches that step, the workflow calls a URL you own with a body describing the file and any values an earlier step read out of the document. Your service gets structured data the moment the document is processed, instead of polling for changes.

Can I send my own JSON instead of the default payload?

Yes. Send to Another App sends a standard payload of file details by default, and you can replace it with a JSON body you write. Inside it you insert values by clicking them in the panel: source values such as the file name and the source, plus every field you named in a Read Details from File step that runs earlier in the workflow.

How do I authenticate the webhook call?

The step offers three choices. No key needed sends no credential, which suits an endpoint protected another way. Bearer token sends the value as an Authorization: Bearer … header. API key sends it as an X-API-Key header. Pick one of the latter two for anything reachable from the public internet, and reject requests that arrive without one.

Webhook vs Zapier: which should we use for our ERP?

If you own the ERP endpoint, the webhook usually wins. A direct call removes a third party from the path, removes a per task price that scales with volume, and leaves one log to read when something fails. Zapier and Make are stronger when neither end is yours, or when the people maintaining the connection do not write code.

Can the webhook fire only after a human approves?

Yes. Put Ask a Person to Approve before the webhook. That step pauses the workflow, and nothing downstream runs until somebody decides. Connect the webhook to the approved exit and it fires only on approval. The rejected and expired exits can go elsewhere, or nowhere, in which case nothing happens and the outcome is still recorded.

Does it work with files in SharePoint or Google Drive?

Yes. The webhook is an action, so it works behind any source. A workflow that watches a SharePoint library, a Google Drive folder, a Slack channel, or a mailbox can end in a call to your API. Files in connected storage are renamed and moved in place there, and nothing is copied into The Drive AI without a Save a Copy step.

Start with one endpoint

Write the smallest endpoint that logs what it receives, then build one workflow that reads a single document type and posts its fields there. Once real data arrives in a usable shape, the rest is mapping. Create a workflow, see how the other steps fit together on the Workflows page and in the complete guide to automated document workflows, and see the full pipeline in accounts payable workflow automation.