Send approved Parsedit extractions as JSON POSTs to your HTTPS endpoint, with notes on payloads, timing, and when to prefer the REST API. Send approved Parsedit extractions as JSON POSTs to your HTTPS endpoint, with notes on payloads, timing, and when to prefer the REST API.
Create your first parser in minutes. No code, no setup calls.
Authorize Parsedit from Zapier, map Upload Document or New Parsed Document to a parser, and manage connections from the Integrations page.
Native destinations cover Sheets, QuickBooks, Xero, and Zapier. When your system of record is custom, you want a JSON POST you control. That is the webhook destination: extracted fields to your HTTPS endpoint when a document is delivered.
This is document delivery, not Stripe billing webhooks.
Approve, POST JSON, upsert, acknowledge.
On delivery, Parsedit POSTs a JSON object with the document’s extracted fields as key-value pairs, values formatted as readable strings. Exact envelope details and verification options are in Webhooks and the REST API.
Configure the endpoint URL on the parser (or via programmatic subscriptions where documented). Use HTTPS only.
Keep auto-send off until your endpoint acknowledges cleanly and your field schema is stable.
Before enabling delivery:
| Need | Prefer |
|---|---|
| Point JSON into your API | Webhook destination |
| Glue to SaaS without code | Zapier |
| Upload files programmatically / full control | REST API |
| Human review UI + finance connectors | Parsedit app + optional webhook |
Inbound: to push files into Parsedit, use intake webhook/API paths described in Document intake, not the outbound destination.
Choose send mode deliberately. Each document separately means multiple POSTs. Everything together means one larger payload. Send modes.
Use Parsedit for extraction and review; use your API for domain logic. Soft CTA: pilot with manual Save & send and a staging endpoint.
Store a unique key from each POST:
vendor_name + invoice_number + invoice_dateOn duplicate keys, return 200 without creating a second business object. Retries happen; your consumer must tolerate them.
v1/invoices)Do not point production auto-send at an endpoint that only works on your laptop.
Publish an internal markdown table of parser keys your API accepts. Require a PR when keys change. Parsedit template edits are easy; silent consumer breaks are not. Pair schema changes with consumer version bumps.
Your app exposes POST https://api.example.com/hooks/parsedit/invoices.
invoice_number + vendor_name.Then point the parser webhook at staging, Save & send three invoices, confirm upserts. Only then consider auto-send.
Keep a checked-in sample payload from a real (redacted) send. Run it in CI against the consumer. When template fields change, update the fixture in the same PR.
If you do not need custom code, prefer native Sheets/QuickBooks/Xero destinations first. Webhooks shine when your system of record is already an API.
Document your timeout and retry expectations next to the endpoint code. Parsedit delivery plus your load balancer idle timeouts are a common source of “duplicate” posts when the client retries a slow 200.
Include POST expectations, idempotency, and when to prefer native connectors. That matches how engineers search and how ops evaluates build vs buy.
Are webhooks signed? Signed delivery and verification are documented in the API/webhooks docs. Implement verification before production.
Can we filter which fields are sent? Shape the parser template; unused fields should not be in the template if you do not want them.
What about binary PDFs? Destination focus is extracted fields. Use storage links or API retrieval patterns as documented when you need the file bytes in your system.
Stand up a staging endpoint, send one reviewed document, verify the JSON. Create an account.