Sandbox Guide

​

How the Sandbox Differs from Live

• Webhook events are triggered by you. Within the sandbox, we provide developers with complete control over the timing of webhook event triggers through the /v1/webhooks/trigger endpoint. This endpoint allows developers to manually and programmatically simulate the occurrence of various webhook events, thereby facilitating robust and repeatable testing of their event-handling logic. See Triggering Events in Sandbox.
• Invite links are non-functional. Invite links returned by the sandbox POST /v1/invites endpoint will not send real emails or allow tenants to complete an application. They are intended solely for testing purposes, to allow developers to validate their integration before going live.
• Bond documents are a sample. Bond document_link URLs returned in the sandbox always return the same sample PDF, whichever bond they belong to.

​

Pre-Seeded Sandbox Entities

​

Triggering Events in Sandbox

POST /v1/webhooks/trigger

​

Request Body

{
  "event_type": "application.status.started",
  "invite_id": "inv_xyz789"
}

​

Available Event Types for Sandbox

• applicant.status.started (requires invite_recipient_id)
• applicant.status.submitted (requires invite_recipient_id)
• application.status.started (requires invite_id)
• application.status.submitted (requires application_id)
• application.status.pending (requires application_id)
• application.status.approved (requires application_id)
• application.status.denied (requires application_id)
• bond.status.issued (requires application_id)
• bond.status.canceled (requires bond_id)

• applicant.status.started for a recipient whose invite has no application yet creates the application and emits application.status.started in addition to applicant.status.started for that recipient. The other recipients on the invite remain not_started.
• applicant.status.started for a recipient whose application already exists moves only that applicant to started.
• applicant.status.submitted moves that applicant to submitted. If it is the last applicant on the application still outstanding, the application also moves to submitted and an application.status.submitted event is emitted.
• The application-level events emit applicant events too: application.status.started (with an invite_id) emits an applicant.status.started event for every recipient on the invite, and application.status.submitted (with an application_id) emits an applicant.status.submitted event for every applicant that had not already submitted. You can use them as shortcuts instead of triggering an event for each applicant, but the two approaches can’t be mixed freely: application.status.started returns a 409 once an application exists for the invite, and application.status.submitted requires every applicant to have at least started, so it returns a 400 if any recipient is still not_started.

{
  "event_type": "bond.status.canceled",
  "bond_id": "bond_def456"
}

​

Response

{
  "event_id": "1761580894123456",
  "event_type": "application.status.submitted",
  "occurred_at": "2025-07-28T18:27:54.690Z",
  "data": {
    "application": {
      // ... application data
    }
  }
}

​

Testing Workflow

1. Create an invite using the POST /v1/invites endpoint
2. Trigger application started event using the POST /v1/webhooks/trigger endpoint with the invite ID (or trigger applicant started for each invite recipient, the first one creates the application)
3. Trigger application submitted event using the POST /v1/webhooks/trigger endpoint with the application ID (or trigger applicant submitted for each invite recipient, the last one moves the application to submitted)
4. Trigger application approved event using the POST /v1/webhooks/trigger endpoint with the application ID
5. Trigger bond issued event using the POST /v1/webhooks/trigger endpoint with the application ID