Before your developer wires lien deadlines into the invoice system

Credit teams that track lien deadlines in a spreadsheet often get to the same point: someone asks whether the invoice system could flag the dates on its own. If LienDeadline is on the list, here's what's useful to know before the developer starts.

Test first, without a key. There are public demo routes, /api/v1/demo/calculate-deadline and /api/v1/demo/supported-states, plus a browser playground and a Swagger explorer that use them. They save no projects and send no email. Use made-up invoices there, not customer data.

The real routes need a customer key. /api/v1/calculate-deadline and /api/v1/supported-states return a 401 with an invalid_credentials code if the request has no valid key. Keys come from API support, are shown once when issued, and go in an Authorization: Bearer header from your server. A logged-in browser session doesn't count, and keys shouldn't sit in query strings, browser storage or logs.

Know what a response is. You send an invoice date, a two-letter state code, a role (supplier, contractor or subcontractor) and a project type (commercial or residential). You get back a projection from the invoice date: preliminary notice and lien filing dates, with warnings. It's stateless, and repeated calls create no project or charge. It's also not a reviewed statutory date. The docs are clear that public supplier date calculations cover reviewed Florida and Kansas scenarios, and that other states need qualified review.

Zapier is separate. The Zapier integration uses its own OAuth endpoints, not customer API keys.

A reasonable first build is a nightly job that runs open invoices through the endpoint and puts anything with a warning, or anything outside reviewed coverage, in front of a person. The endpoint list and sample payloads are in LienDeadline's API documentation.

From the LienDeadline team. General information, not legal advice; have a qualified reviewer check the facts on any live job.