Zapier
Wire DualEntry into thousands of apps with Zaps that create records, update them, look them up, and fire when new ones appear. No code, no middleware for you to run.
Overview
The record you need in DualEntry usually starts life somewhere else: a closed deal in your CRM, a form submission, a row someone added to a spreadsheet, a payment notification in an inbox. Zapier is the wiring between those systems and your ledger. DualEntry publishes a Zapier connector so that wiring stops being a script one person on your team quietly maintains.
The connector currently publishes 39 actions across 19 DualEntry resources, and they fall into three kinds of step. Create and update actions write into DualEntry. Search actions look existing records up. Polling triggers start a Zap when new records show up in DualEntry. Every step authenticates with one organization-scoped Public API key sent as an X-Api-Key header, not OAuth and not the session behind the DualEntry UI.
So data genuinely moves both ways, though not in the same step. Invoices, bills, customers, vendors, sales orders, and customer payments support all four capabilities: create, update, polling trigger, and search. Journal entries and direct expenses can be created and searched. A longer list, including items, purchase orders, vendor payments, cash sales, customer and vendor credits, bank transfers, customer deposits, refunds, and classifications, is available to search.
Two mechanics are worth knowing before you build. Triggers send GET calls on Zapier's schedule rather than receiving webhooks pushed out of DualEntry, so there is polling latency and Zapier's normal deduplication rules decide what counts as new. Updates fetch the existing record, strip read-only fields, merge your Zap inputs over the top, then PUT the full payload back, which means fields you leave blank keep their current values and line arrays are replaced wholesale rather than patched line by line.
Invoices
Bills
Customers
Vendors
Sales Orders
Customer Payments
Journal Entries
Direct Expenses
Items
Data synced
The integration syncs the following data types:
- The Zapier app uses custom authentication with a static API key rather than OAuth, sending the key as an X-Api-Key header on every call.
- You generate an organization-scoped Public API key in DualEntry under Organization Management, in API Keys, with the authentication scopes the Zap steps require, then paste it when Zapier prompts for credentials.
- Zapier validates the key with a connection test against GET /public/v2/health/, and a 200 response completes authentication.
- The default base URL is https://api.dualentry.com, and private deployments override it, so agree the environment before building Zaps.
- A single key authorizes both directions, covering the create and update actions that write into DualEntry and the triggers and searches that read out of it.
- Polling triggers are available for invoices, bills, customers, vendors, sales orders, and customer payments, letting new DualEntry records start a Zap in another system.
- Triggers send repeated GET list calls on Zapier's schedule rather than receiving real-time webhooks pushed from DualEntry, so there is inherent polling latency.
- Zapier deduplicates polled records using the platform's normal polling rules, so a record that has already started a Zap is not reprocessed.
- Because polling GET calls run on a schedule, they have to respect DualEntry API rate limits; this page defers the specific numbers to the separate rate limiting guide.
- Create actions write new records into DualEntry for invoices, bills, customers, vendors, sales orders, customer payments, journal entries, and direct expenses.
- Transactional records such as invoices and bills expose a record status field, and selecting Draft rebuilds the Zapier form so fields the product does not require for drafts become optional.
- Field labels and required flags for every create action are generated from a single schema manifest in the connector package, which is the source of truth rather than hand-written per action.
- Missing required fields, invalid enum values, or breaching draft versus posted rules return a 422 validation error, with the API detail array formatted into a readable message where possible.
- Populate reference fields from the dynamic dropdowns rather than typing numeric IDs, since hard-coded IDs go stale when master data changes.
- Update actions are published for invoices, bills, customers, vendors, sales orders, and customer payments, the six resources that support the full capability set.
- Each update performs a GET on the existing record, strips read-only fields, merges the values supplied by the Zap, then PUTs the complete payload back to DualEntry.
- Fields you leave out of the Zap step keep their existing API values after the merge, and only the fields you supply override them.
- PUT replaces line arrays wholesale rather than patching individual lines, so any Zap that edits lines must supply the complete line array or the previous lines are lost.
- For purely additive workflows, use create-only Zaps to avoid overwriting line detail through the merge.
- Search steps read DualEntry records mid-Zap and return them to the rest of the workflow, covering invoices, bills, customers, vendors, sales orders, customer payments, journal entries, and direct expenses.
- Search is also available for items, purchase orders, vendor payments, cash sales, customer credits, vendor credits, bank transfers, customer deposits, customer refunds, vendor refunds, and classifications.
- Zapier's publishing rules prohibit consecutive search steps, so you cannot chain two lookups back to back in one Zap.
- A Zap must never end with only a search step, which is a Zapier platform restriction rather than a DualEntry one.
- A search that finds nothing returns a 404, while a key without permission for that record type or company returns a 403.
- Six dropdown lists pull live DualEntry master data into Zap step configuration: companyList, customerList, vendorList, accountList, itemList, and classificationList, backed by the companies, customers, vendors, accounts, items, and classifications public API slugs.
- The customer, account, and classification lists are company-scoped, so you must select a company in the Zap step before the dropdown loads and it shows only records belonging to that company.
- The company, vendor, and item lists are not company-scoped and load without a company selection.
- Using dropdowns instead of hard-coded numeric IDs keeps Zaps working when master data is renamed or reorganized.
- An empty dropdown usually means the underlying master data does not exist yet in DualEntry, or the selected company filter excludes it.
- A 401 response means the API key was revoked or mistyped and triggers Zapier's reauthentication flow, resolved by creating a new key under Organization Management and updating the Zapier connection.
- A 403 on an action means the key lacks permission for that record type or company, resolved with a correctly scoped key or an adjustment to DualEntry role permissions.
- A 404 means the record was not found, and a 422 means validation failed; for 422 the connector formats the API detail array into a single message where possible, and the loc and msg fragments identify the offending field.
- If the connection test fails, verify the API key, confirm the base URL for private stacks, and check that GET /public/v2/health/ returns a 200.
- Build and validate Zaps against a non-production DualEntry organization, mapping all required fields and running end-to-end tests before pointing them at production.
Key Features
- 39 actions across 19 resources
Create, update, and search steps are generated from a single schema manifest in the connector, so field labels and required flags stay consistent across every record type. - Writes into DualEntry from any trigger app
A Zap can create invoices, bills, customers, vendors, sales orders, customer payments, journal entries, and direct expenses from whatever app started the run. - Updates that respect the rest of the record
Update actions read the existing record, merge only the fields you supplied, and put the whole payload back. Send complete line arrays when you change lines, because PUT replaces the array rather than patching it. - Polling triggers on your core records
Invoices, bills, customers, vendors, sales orders, and customer payments each support a polling trigger, so DualEntry activity can start work in other systems on Zapier's schedule. - Search steps for lookups mid-Zap
Items, purchase orders, vendor payments, cash sales, customer and vendor credits, bank transfers, customer deposits, refunds, and classifications can all be searched. Zapier's own publishing rules forbid consecutive search steps and Zaps that end on a search alone. - Dynamic dropdowns instead of hard-coded IDs
Six list dropdowns cover companies, customers, vendors, accounts, items, and classifications. The customer, account, and classification lists are company-scoped and load only after you pick a company in the step, which keeps IDs from going stale when master data is renamed. - Draft-first creates for transactional records
Records such as invoices and bills expose a record status field. Choose Draft and the form rebuilds with several fields optional, so you are not forced to supply values the product does not require yet. - One organization-scoped key, tested before you build
You create a Public API key under Organization Management, in API Keys, and paste it into Zapier. Zapier runs a connection test against the health endpoint and a 200 completes authentication. A revoked or mistyped key returns 401 and triggers Zapier's reauthentication flow. The connector package itself is maintained by DualEntry engineering.
FAQ
No. The DualEntry Zapier app uses custom authentication with a static API key, sent as an X-Api-Key header on every call. It does not use OAuth and it does not share a session with the DualEntry UI; OAuth for end users is a separate Public API surface that this connector does not implement.
You create an organization-scoped Public API key under Organization Management, in API Keys, with the scopes your Zap steps need, then paste it when Zapier asks for credentials. Zapier tests the key against GET /public/v2/health/ and a 200 response completes the connection.
Invoices, bills, customers, vendors, sales orders, and customer payments support the full set: create, update, polling trigger, and search. Journal entries and direct expenses can be created and searched.
Search is additionally available for items, purchase orders, vendor payments, cash sales, customer credits, vendor credits, bank transfers, customer deposits, customer refunds, vendor refunds, and classifications. In total the connector currently publishes 39 actions across 19 resources.
Yes, but in separate steps rather than as one continuous sync. Create and update actions write into DualEntry from whatever app triggered the Zap. Polling triggers and search steps read out of DualEntry so its records can drive work elsewhere.
Which direction you get depends on the step you add, and on the record type: only the six fully supported resources offer both a write action and a polling trigger.
Triggers poll rather than receive webhooks. They send repeated GET list calls on Zapier's schedule instead of DualEntry pushing real-time events out, so there is polling latency between a record appearing in DualEntry and the Zap running.
Zapier deduplicates polled records using the platform's normal polling rules, so a record that has already started a Zap will not be picked up again on the next poll.
Yes. Because triggers send GET calls on Zapier's schedule rather than receiving pushed webhooks, polling has to respect DualEntry's API rate limits. The integration documentation points to the separate rate limiting guide for the applicable limits rather than stating numbers on the Zapier page itself.
Zapier's own publishing rules add two constraints worth knowing while you build: consecutive search steps are not allowed, and a Zap must never end with only a search step.
The connector surfaces the API response so you can act on it. A 401 means the key was revoked or mistyped and triggers Zapier's reauthentication flow. A 403 means the key lacks permission for that record type or company. A 404 means the record was not found. A 422 is a validation failure, and the connector formats the API detail array into a single readable message where it can, with the loc and msg fragments naming the offending field.
One failure mode is worth guarding against specifically: because updates merge your inputs and then PUT the full payload, a PUT replaces line arrays wholesale. If a Zap changes lines, supply the complete line array, or use create-only Zaps for additive workflows. Build and test against a non-production organization before pointing anything at production.
.avif)