The signing inputs mount into the agreement's own signature section: an authorisation checkbox, a typed full legal name that must match the owner name, and a drawn signature. Approve & Sign writes the signature; Decline opens an are-you-sure dialog requiring a written reason of at least three characters.
Also called: approve change order · decline change order · sign extras · authorize the change
- 1The portal renders the agreement with signaturePadSlot filled — 'the customer signs ON the document, not next to it'.
- 2The sign endpoint requires a typed name and a real drawn image ('Draw your signature to sign.') and refuses anything not in 'sent' or 'partially_signed'.
- 3The link id is the auth; the change order must belong to that link's project and org, and a mismatch returns not-found rather than leaking that the id exists.
- 4Signing records the rendered agreement text the customer actually saw.
- 5Decline records the reason: 'Tell your builder why you're declining — this is recorded on the change order.'
- 6On success: 'Signed — thank you! Your builder has been authorized to proceed with this change.'
The slot's purpose is written into the component: it is 'rendered inside section 6's customer block INSTEAD of the recorded signature (the portal sign flow mounts its inputs here so the customer signs ON the document, not next to it).' A signature captured on a separate screen from the terms is a weaker record than one captured on the page itself.
- Verbal or SMS approvals for priced scope changes
- Signatures captured away from the terms they authorise
- Declines with no recorded reason
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →