All integrations
Make.com automation
IN + OUT — /api/webhooks, POST /api/extract/infer
Make.com is the glue layer between thousands of apps, and Dynamite Docs plugs into it with the same two primitives it exposes: outbound webhooks that fire when an extraction completes, and the REST API with scoped tokens that any Make module can call. Together they make a document workflow you can assemble visually. A PDF lands, extraction finishes, and Make pushes the rows to a spreadsheet or a CRM.
Try it free or read the API & webhooks docs.
Extraction is one step in a chain, not the whole chain
- A document is rarely the end of the process. The data usually has to travel on to a ledger or a colleague. Manual hand-off makes each hop a re-keying session.
- Building bespoke glue code for every destination is expensive and brittle; the first vendor change breaks the pipeline.
- Teams without an engineering bench still have real automations to run, but the tooling to run them assumes a developer is available.
- The hard part is knowing when extraction actually finished and getting the data in a shape the next app can consume.
How the Make.com connection works
01 — Create a Make.com webhook
In Make.com, add a Webhooks module with an Instant trigger and copy its public endpoint URL. That URL is where Dynamite Docs will POST the extraction.completed event.
02 — Register it as a Dynamite Docs webhook
In the Dynamite Docs workspace, create a webhook pointing at the Make URL. The endpoint is SSRF-guarded to public hosts and signed with HMAC-SHA256 so Make can verify the event.
03 — Build the scenario
Make receives the payload, columns, rows, metadata, and confidence, and routes it through the scenario: map the fields into a Sheets row or a HubSpot contact.
04 — Send documents in via the API
The IN direction works the same way. A Make HTTP module POSTs a file to /api/extract/infer with a scoped token, and the extracted table comes back in the response for the scenario to use.
The Make.com surface
Everything Make needs is the same surface every other connector uses:
- Trigger — extraction.completed → Make webhook
- Payload — columns, rows, metadata, confidence
- Signature — HMAC-SHA256 (X-Dynamite-Signature)
- Send documents in — POST /api/extract/infer with a token
- Destinations — 2,000+ apps via Make modules
- Retries — backoff + jitter, up to 3 attempts
A realistic example
A receivable automation assembled in Make:
| Step | Module | What happens |
|---|
| Trigger | Webhooks (instant) | Receives extraction.completed from Dynamite Docs |
| Parse | Router | Splits by docType, invoice vs. receipt |
| Transform | Google Sheets row | Maps columns to the receivable ledger |
| Notify | Slack message | Posts a summary to the team channel |
Make.com turns extraction into a node in a bigger graph
Dynamite Docs never needs a bespoke Make app. Because outbound webhooks and the REST API are first-class public surfaces, Make.com consumes them directly. An Instant webhook trigger stands in as the event source, and HTTP modules call the API for the in-bound direction. So every Make scenario a team builds uses the same documented primitives they could call without Make at all. Make just removes the need to write the glue by hand.
The webhook direction is the reliable trigger. When an extraction completes, Dynamite Docs POSTs the full payload of columns, rows, metadata, docType, and average confidence to the registered Make URL, signed with HMAC-SHA256 over the raw body. Make verifies the signature before the scenario runs, which means the automation cannot be spoofed by anyone who can POST to the same URL. Delivery retries with exponential backoff on network errors, 429s, and 5xx, so a transient Make outage does not silently drop an event.
The API direction keeps Make useful as a destination. A scenario that starts elsewhere, from a form submission or a scheduled run, can POST a document to /api/extract/infer using a scoped API token and get the structured table back in the JSON response. Tokens are revocable per user and carry the same per-document page caps and monthly allowance as interactive use, so automation cannot become a back door around the quota model.
The honest limits are the connector’s own: webhook events carry extracted data, not the original file bytes, and the SSRF guard means the Make endpoint must be a public HTTPS URL. For teams already on Make, the integration is a fifteen-minute setup: create the webhook, register it, build the scenario, and test with a real extraction. For teams that want the same result without Make, the underlying webhooks and REST API are the documented building blocks.
What the Make.com connection does and does not
Does
- Triggers Make.com scenarios with a signed extraction.completed webhook the moment an extraction finishes.
- Lets Make POST documents into /api/extract/infer with a scoped token and receive the structured table.
- Retries transient delivery failures so a Make outage does not silently drop an event.
Does not
- Does not require a private Make app or Make-specific credentials. It uses the public webhook and REST API surfaces.
- Does not send original file bytes in webhook events. The payload carries the extracted data.
- Does not let automation exceed the same page caps and monthly allowance as interactive use.
Why Make.com needs no separate app
Make.com works because it runs on the public webhook and REST API surfaces. Nothing extra to install.
One trigger reaches 2,000+ destinations. The extraction event is a first-class citizen in any Make scenario.
The same primitives stay honest: signed, retried, quota-governed, and documented on their own pages.
Questions, answered
How do I connect Make.com to Dynamite Docs?
Add an Instant webhook trigger in Make.com, copy its public URL, and register it as a webhook endpoint in Dynamite Docs. Make verifies the HMAC-SHA256 signature, then your scenario runs on extraction.completed.
Can Make.com send documents into Dynamite Docs?
Yes. A Make HTTP module POSTs the file to /api/extract/infer using a scoped API token and reads the structured rows back from the response.
Is this a native Make.com app?
No, and that is the point. It uses the same public webhook and REST API surfaces that work without Make, so the integration never depends on a private app.
What about retries?
Webhook delivery retries on network errors, 429s, and 5xx with exponential backoff and jitter, up to three attempts.
Document workflows it feeds
Open app, no payment details.