Skip to main content
Webhooks allow you to receive real-time notifications when important events occur in the I-9 process. You can use them to trigger downstream workflows, update your internal systems, or monitor form progress without polling our APIs.

Events

When an event occurs, a POST request is sent to the configured webhook endpoint. All event types are included—you cannot subscribe to individual events.
Webhooks are distinct from the postback serviceWhile webhooks send lightweight notifications about key events (such as form submission or case updates), the postback sends the full completed form data, including the actual form and its values.The postback is sent to the postback.target.url specified in the employers object and is typically used for processing the full I-9 record after completion. Read more here: Receive Completed I-9 Data.

Sample payloads

Form I-9 was countersigned (employee.i9Complete)

Sent when Section 2 is countersigned.

E-Verify case details updated (employee.everifyCaseUpdate)

Sent when an employee’s E-Verify case status changes.

Employee profile updated (employee.profileUpdated)

Sent when the employee’s profile is updated.

I-9 expiring documents (employee.upcomingExpiration)

Sent 30 days before a document expires, or immediately upon submission if within 30 days.

Employee restarted Form I-9 (employee.i9Restarted)

Sent when an employee restarts the Form I-9 process. Workflow
  1. The employee begins completing Section 1.
  2. The employee or an administrator restarts the Form I-9 process.
  3. A new Form I-9 process is initiated.
  4. The employee.i9Restarted webhook is sent.
NoteThis event does not include a submission object because a new submission has not yet been created. The new submission ID is included in the subsequent employee.section1Complete webhook after the employee completes Section 1.

Employee submitted form (employee.section1Complete)

Sent when the employee completes Section 1.

Employee submission rejected (employee.submissionRejected)

Sent when an administrator rejects an employee’s Form I-9 submission during the review process. Workflow
  1. Employee completes Section 1.
  2. An administrator reviews the submission and completes Section 2.
  3. The administrator rejects the Form I-9 submission and provides a rejection reason.
  4. The employee.submissionRejected webhook is sent.

Employee submission reverified (employee.submissionReverified)

Sent when a Form I-9 has been successfully reverified through Supplement B. Workflow
  1. Employee has an existing completed Form I-9.
  2. An administrator initiates the Supplement B reverification process.
  3. The administrator reviews and re-examines the employee’s documentation as part of reverification.
  4. The reverification is completed.
  5. The employee.submissionReverified webhook is sent.

Authorized representative mismatch (employee.i9AuthRepMismatch)

Sent when an authorized representative identifies a mismatch while reviewing an employee’s documents during remote countersigning. Workflow
  1. The employee is configured to use remote countersigning with an authorized representative.
  2. The employee completes Section 1.
  3. The authorized representative reviews the employee’s documents during the remote countersigning process.
  4. The authorized representative indicates that the employee’s presented documents do not match the information entered in the Form I-9.
  5. The employee.i9AuthRepMismatch webhook is sent.

E-Verify authentication result (employer.everifyAuthenticationResult)

Sent when E-Verify credentials are authenticated or revalidated.

Configuration

Webhooks are configured at the employer level using the /employers POST endpoint. You can update the callback URL later using the /employers/{employerId} PATCH endpoint. When configured, you will receive all webhook event types.

Request

The webhook object contains the configuration for where webhook events will be delivered.
Sample Request

Webhook object fields

For full employer configuration details, see Configure Employers.

Authentication

Symmetry supports multiple authentication schemes when sending webhook requests:
  • None – no authentication header is included
  • Basic – Authorization: Basic <base64(username:password)>
  • OAuth2 – Symmetry will request an access token and include it in the Authorization: Bearer <token> header
Authentication credentials are included in the request header when Symmetry sends webhook payloads to your system. This ensures secure delivery and proper endpoint validation.
If using OAuth2, ensure your token endpoint supports Client Credentials grant type.

Failure notifications

You can optionally configure a dedicated email address to receive notifications when webhook deliveries fail. Notifications are sent only after all retry attempts have been exhausted. To configure the notifications, specify the target email address within the failureNotificationEmail field in the webhook object when setting up or updating each employer.