Signing Forms via the API

Most employee and employer authorization forms are collected when users go through Check Onboard or an embedded Component. Under the hood, those Components sign each form and store the resulting PDF. For partners who build their own signing experience, Check exposes that same capability directly through the API.

Signing a form through these endpoints produces the same result as signing it through a Component: Check renders and stores the signed PDF and returns a document field containing the ID of the generated document, which Check retains as the authoritative record of the signature. The only difference is where the signature is collected — through Check's hosted Component, or in your own UI.

Employee forms

Employee withholding forms (such as federal and state W-4s) can be signed and submitted through the Sign and submit an employee form endpoint. Signer information is drawn from the employee record, and the signing IP address is captured automatically from the request.

For more detail, see the Custom Employee Onboarding Guide.

Employer forms

Employer authorization forms can also be signed and submitted through the API, mirroring the employee flow:

• Company authorization forms — Terms of Service and Debit Authorization
• Company filing authorization forms — IRS Form 8655 and state Power of Attorney / filer and remitter authorization forms

The flow uses the following endpoints:

1. GET /companies/{company}/forms?type=company_authorization — list Terms of Service and Debit Authorization forms
2. GET /companies/{company}/forms?type=company_filing_authorization — list Form 8655 and state authorization forms
3. POST /companies/{company}/forms/{form}/preview — render the PDF for review
4. POST /companies/{company}/forms/{form}/sign_and_submit — sign and store the document

Unlike employee forms, signer information for employer forms is drawn from the company's Signatory. If a company has a single signatory, it is used by default. If a company has more than one signatory, pass the intended signatory in the request; a request that does not resolve to exactly one signatory returns a validation error. As with employee forms, the signing IP address is captured automatically from the request.

Partner responsibilities

Because these endpoints bypass Check's hosted signing experience, the signing partner is responsible for presenting the correct, current version of each agreement to the appropriate signer and collecting affirmative consent in their own UI before calling sign_and_submit. Check can verify the form and signatory associated with a submission, but relies on the partner to attest that the agreement was displayed and knowingly signed. These obligations are set out in the additional terms required to enable this feature.