Schedule a network notarization
Create a future appointment with an explicit timestamp and verify how your account schedules notary notifications.
Confirm your scheduling policy
The appointment time and the first notary notification are separate. Your account’s automatic-dispatch and strict-schedule settings determine when an open call is attempted.
Without the intended strict-scheduling policy, a creation-time open call can ignore the later timing. Notification may also intentionally precede the appointment.
Send the scheduled request
Set notarization_timing_type to notarize_later and include session_timing. Omit a specific notary email for the configured pool workflow.
{
"notarization_id": "order-1042",
"signing_type": "ron",
"session_type": "gnw",
"notarization_timing_type": "notarize_later",
"all_signers": [
{
"first_name": "Sam",
"last_name": "Signer",
"email": "sam@example.com"
}
],
"session_timing": "2030-01-15T10:00:00-05:00"
}Resolve the exact instant
The example 2030-01-15T10:00:00-05:00 represents 15:00 UTC. Calculate the offset for the appointment date and timezone; a summer and winter appointment may need different offsets.
| Input | Meaning |
|---|---|
| 2030-01-15T10:00:00-05:00 | 10:00 at UTC−05:00; 15:00 UTC. |
| 2030-01-15T15:00:00Z | 15:00 UTC. |
| A local time without an offset | Avoid: the intended instant is ambiguous. |
Verify the invitation display, stored appointment, actual dispatch, and reschedule behavior across the timezones your integration serves.
Change the appointment
Call PUT /sessions/{bn_session_id}/reschedule with the new timestamp. A successful reschedule changes meeting metadata; the handler does not reserve or enforce notary availability.
- Confirm participant notification policy for rescheduling.
- Handle session_rescheduled updates.
- Check that reminders and the intended dispatch time follow the new appointment.
{
"session_timing": "2030-01-16T11:30:00-05:00"
}When the signer should choose
Do not substitute an arbitrary timing value for a signer-selected scheduling workflow. The current timing aliases require end-to-end verification before they can be offered as a reliable API recipe.
Do not send let_signer_choose or on_demand without a confirmed integration contract. Unknown timing values can fall through to immediate behavior.
Acceptance checks
Complete this small matrix before launching scheduling.
- A future appointment with the correct displayed local time.
- A daylight-saving boundary and a UTC timestamp.
- A reschedule before dispatch and a cancellation before the appointment.
- A session with no accepting notary and its customer-facing recovery path.