Skip to main content
Conditional logic controls which fields and sections an application needs at a given point. Different business types need different documents. Data you enter in one section can also add or remove requirements elsewhere. The schema expresses this with JSON Schema if/then rules, so your integration can adapt to schema changes instead of hardcoding field requirements.

​
Nature of business

The primary conditional driver is Nature of Business (NOB). This classification is set during application creation and determines which sections and fields appear. For example, a cryptoExchange application may require different documentation than a trust application.

​
How conditionals work

The allOf array in the schema contains if/then blocks:
  • The if clause checks the value of a parent field (most commonly nature_of_business).
  • When the condition is met, the then clause adds fields to the required array, making them mandatory.
Supported condition types: The following example shows an exact string match condition:
Here, when natureOfBusiness is cryptoExchange, the schema requires cryptoExchangeLicenseNumber. The same if/then pattern works for all types in the preceding table. Swap in the right JSON Schema keyword in the if block: enum for OR lists, contains for arrays, not for negation.

​
Conditional side effects

After saving a section that contains a conditional parent field, other fields or sections may become required. For example, country=US may require a state field. businessWebsiteProvided=false may require noWebsiteReason. beneficialOwnersExist=true may turn on the beneficial owners section. Array sections can also activate this way. The API tells you through three signals:
  1. sectionsChanged flag: Returned in every save response. When true, the section list has changed and you should re-fetch sections.
  2. fieldsChanged flag: Returned in every save response. When true, the server modified one or more field values during save, for example clearing a field that no longer applies after a conditional change.
  3. Updated sections array: The response includes the current status of all active sections, not just the one you saved.
Always check sectionsChanged after you save section data. If you skip it, you may submit an incomplete application or miss new required sections. When sectionsChanged or fieldsChanged is true, re-fetch the schema with ?resolved=true. That returns the current required fields for your saved data.

​
Mutually exclusive groups

Some conditionals create mutually exclusive branches. For example, different variants of basic_business_info may exist for different NOB values. Only one branch’s fields are required at a time. The schema enforces this automatically.

​
Design considerations

  • Integrations that skip re-fetching after a sectionsChanged response risk submitting incomplete applications.
  • Client-side validation against the schema (minLength, pattern, enum) before submitting reduces round-trips and improves the user experience.
  • Add ?resolved=true to the schema endpoint. You get only the fields that are active for your saved data. You do not need to evaluate conditional rules in your own code.