Global Constraints

\<font color="#78b5c7">\</font> topic type constraint purpose explain global field classification and validation rules used across apis audience api integrators and client developers applies to apis that use field‑level validation and classification does not apply to internal batch processing, non‑request‑based integrations, or apis without request payloads api fields are categorized to communicate how they should be populated , and how validation behaves these categories are designed to support a wide range of client implementations—even within the same industry—because different merchants have different data availability and business models while originally introduced in the apis, these field classifications are used consistently across apis that accept structured request payloads required fields required fields must be included for the request to be accepted if a required field is missing or invalid, the api can reject the request (validation error) required fields typically establish the minimum identifiers and context needed to process the event client behavior expectation if a field is required, you should always send it with a valid value imperative fields imperative fields should be sent whenever your implementation has the ability to provide them imperative does not mean “send it sometimes ” it means if your system collects or stores this data as part of your integration, send it on every request if a value is occasionally unavailable (for legitimate reasons), you may still send the field with a blank/empty value , depending on your payload conventions and validation rules imperative fields materially improve fraud evaluation by enhancing correlation and context they are labeled imperative because they are high value signals, but we understand they may not be available across all clients client behavior expectation if you can provide an imperative field, send it every time (even if occasionally blank) if you cannot provide an imperative field, do not engineer fragile workarounds or placeholder values conditional fields conditional fields become required only when certain conditions are met —for example, based on the value of another field, or when a related field is present conditional rules are used to express dependencies like “field b is required if field a exists” “field c is required if field a has value x” “field d is required if paymenttype is creditcard ” “field e is required if passport number is provided” client behavior expectation when the condition is true → include the conditional field with a valid value when the condition is false → omit the field (or send blank only if your schema conventions require presence) optional fields optional fields may be included at your discretion they are not required for the request to be accepted, and there are no validation dependencies that require them to be present optional fields typically provide additional context or enrichment data that can improve evaluation, reporting, or downstream workflows, but they are not necessary for basic processing client behavior expectation if you have relevant optional data available, include it to improve results and context if you do not have the data, omit the field do not generate placeholder or artificial values simply to populate optional fields see also getting started docid\ mff0kez4dg0xsdeld1tae introduce the apis and their role within the core concepts docid\ n8nqgm3c9vgdxudq54ktl how evaluates fraud risk across events, time, and customer behavior api reference page docid 40scz3hvgitth6c2i6jja field definitions and requirements for every api