Skip to main content
A verification rule says “for stays that look like this, collect this before check-in.” Each rule has a step type, a config, and optional targeting.

​
Step types

​
Stacking and slots

Rules are evaluated in order. What happens when several enabled rules match the same stay depends on the step type:
  • Stacking step types (agreement, mandatory_fee, additional_questions, custom_field_gate): every enabled matching rule applies, in evaluation order. A base agreement plus a per-property addendum both render on the same check-in.
  • One-per-slot step types (id_check, damage_waiver, security_deposit, guest_details, other_guests, guest_registration): the first enabled rule whose targeting matches the stay wins its slot, and every later rule for that slot is skipped.
For one-per-slot types, ordering decides which rule applies. A specific rule must be above a general rule, or it never applies:
If you reverse the order, the catch-all rule always claims the slot. The API does not return an error. Rules never compete across step types. damage_waiver and agreement use different slots, so one waiver and any number of agreements can apply together. When a damage waiver and a security deposit both apply to a stay, the guest chooses one of them.

​
Creating a rule

Call Create Verification Rule to add arrival details. This rule leaves out Airbnb bookings:
requiredFields must be a subset of the collected fields. The API rejects eta when collectEta is false. The following rule adds a deposit for long stays:
holdDaysBeforeArrival (1, 2 or 3, default 3) sets how many days before arrival the card hold is placed. New rules are enabled and appended. They’re added to unfinished stay portals within a few minutes. Move a specific rule above a catch-all rule with Reorder Verification Rules.
Agreement. A document to sign, with no charge attached. Pricing an agreement is rejected; use damage_waiver instead.
Damage waiver. A signature that can carry a price. model is flat, per_night, average_nightly_rate, average_nightly_rate_with_fees, accommodation_fare, or accommodation_fare_with_fees. The last four charge adrPercent percent of the stay’s average nightly rate, average nightly rate including fees and taxes (never lower than the average nightly rate), total accommodation fare, or total accommodation fare including fees and taxes (never lower than the total accommodation fare), with amountInCents set to 0. minInCents and capInCents bound the total; capInCents must be at least amountInCents and minInCents.
Mandatory fee. Same shape as a deposit, without releaseDelayDays or holdDaysBeforeArrival.
Additional questions. Question id values must be unique within the rule. Select questions need at least two options. Other question types take no options.
Other guests. Set minGuests, maxGuests, or both. maxGuests is limited to 50. A rule supports a maximum of 20 fields. Each field needs a unique id.
ID check. Collects an identity document. It requires title and instructions. It also supports requireContactPhoto and autoApprove. Rules created through the API use Conduit’s own ID review. Other verification methods, document options and review flags are set in the app.Guest registration. Registers guests through Chekin. Creating the rule, or updating its config, fails unless a Chekin account is connected.
Custom field gate. Holds check-in until its conditions match. combinator is all or any, with 1 to 20 conditions. A condition reads a reservation custom field (source: "reservation_custom_field" with field), a contact custom attribute (source: "contact_attribute" with attributeId), or the payment status (source: "payment_status", status: "Paid"). Field and attribute conditions take an operator (has_value, has_no_value, equals, not_equals, contains or not_contains, plus greater_than, less_than, before and after for attributes) and a value for every operator except has_value and has_no_value.

​
Targeting

Every criterion you set uses AND logic. Empty or omitted targeting matches every stay. exclude_returning_guests drops the rule for guests who stayed before. This is useful for one-time identity checks.

​
Reordering

Reorder Verification Rules takes every rule in the workspace. Include each current expected_updated_at value:
The API rejects partial lists because accepting one would renumber omitted rules.

​
Editing and deleting

Update Verification Rule cannot change step_type. The supplied config must match the existing step type. config and targeting replace the stored values, so send the full object with only the fields documented here. Use the app to edit rules that have settings this API doesn’t support. Rules backed by an uploaded PDF can’t take config. You can still change name, enabled, targeting and exclude_returning_guests, and edit the document in the app. Rules whose position changes in a reorder get a new updated_at. Read them again before you update them. Delete Verification Rule is permanent. Within a few minutes of a rule change, Conduit updates the stay portals of current and upcoming reservations to match. Steps a guest has started or finished stay as they were, and paid fees keep their amount. Portals with a completed check-in, stays past checkout and test portals don’t change. If a change leaves a guest with nothing left to do, their check-in completes. Changing rules doesn’t delete existing guest submissions.
Priced rules include security_deposit, mandatory_fee, and damage_waiver with a nonzero price. Once the workspace has an active template or stay portals, they need a Stripe account with charges enabled and onboarding finished. To stage a priced rule, create it with enabled: false.