Your first business call with calculate-deadline

If you are deciding whether to adopt the API, this endpoint is your proof point: it tells you whether the team can act before lien-related deadlines.

Endpoint: POST /api/v1/calculate-deadline

Core inputs you provide

• state: A two-letter US state code, e.g. CA.
• invoice_date: Invoice date in YYYY-MM-DD.
• project_type: The type of work, often commercial or your internal taxonomy equivalent.
• role: supplier, contractor, or subcontractor.
• Optional override flags used by engineering teams for edge-case handling.

What each output means for operations

• preliminary_notice_deadline
  • Meaning: final date by which notice-related action should occur.
  • Business move: if this is near, raise a follow-up task before legal review closes the week.
• lien_deadline
  • Meaning: hard date to protect lien rights.
  • Business move: treat as a critical closeout checkpoint.
• preliminary_notice.required
  • true: schedule a required notice action.
  • false: this state may not require preliminary notice for this scenario.
• prelim_deadline_days and lien_deadline_days
  • Positive value: time still available.
• Negative value: deadline already passed and should trigger escalation.

Example: same invoice, two states

Use the same date and project context across CA and TX to test how state logic changes.
That comparison is exactly what most buyers need before building integrations.

Expected workflow outcome

• Confirm both states are in the supported state list.
• Capture if Texas has earlier notice windows than California.
• Decide whether your current reminder cadence needs adjustment for your first pilot.

What teams do when this works in demo

1. They confirm the endpoint returns both dates consistently.
2. They validate their downstream queue triggers can read day counts.
3. They request a short implementation plan only if results map to actual closeout risk reduction.