snapdok

Guides · use case

Claim forms your policyholders can actually complete

Claims arrive from people having a bad week, on whatever device they have, often through an agent or adjuster who is not logged into your portal. That is why claim forms still circulate as PDFs — and why insurers end up maintaining a portal form and a designed PDF form that quietly diverge.

Rendering the portal form with pdf_forms collapses the two into one definition. Policy-number fields, incident-date inputs, damage-type dropdowns and declaration checkboxes all become real AcroForm controls:

curl -X POST https://snapdok.io/v1/render \
  -H "Authorization: Bearer $SNAPDOK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://claims.your-insurer.com/auto/new","format":"pdf","pdf_forms":true,"pdf_form_only":true}' \
  --output claim-form.pdf

Because fields keep their HTML name attributes, filled PDFs coming back by email can be machine-read into the same intake pipeline as portal submissions. Assert X-Form-Fields in your release checks so a portal redesign can never silently ship a claim form with a missing field.

Free keys need no card and include a monthly allowance — get one and try it on your own form. The docs list exactly which controls convert and how edge cases are handled.

Step-by-step guides