---
title: Global Constraints
slug: legacy-fraud-apis/global-constraints
createdAt: 2026-03-04T15:18:41.004Z
---

::::ExpandableHeading
###

**Topic type: Constraint**

:::hint{type="warning"}
**Purpose**: Explain global field classification and validation rules used across Accertify APIs.

**Audience**: API integrators and client developers. 

**Applies to**: Accertify APIs that use field‑level validation and classification. 

**Does not apply to**: Internal batch processing, non‑request‑based integrations, or APIs without request payloads.
:::
::::

Accertify 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 Fraud APIs, these field classifications are used consistently across Accertify APIs that accept structured request payloads.

:::ExpandableHeading
## 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.
:::

:::ExpandableHeading
## 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.
:::

:::ExpandableHeading
## 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)
:::

:::ExpandableHeading
## 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**:

::::LinkArray{contentSource="CUSTOM"}
:::LinkArrayItem
[Getting Started](docId\:Mff0KeZ4dG0xsDELd1tae)

Introduce the Accertify APIs and their role within the Accertify Interceptas Platform
:::

:::LinkArrayItem
[Core Concepts](docId\:N8nqgM3c9VGdXuDq54ktl)

How Accertify  evaluates fraud risk across events, time, and customer behavior
:::

:::LinkArrayItem
[API Reference Page](docId:40sCZ3HvGItTH6c2I6jjA)

Field definitions and requirements for every API
:::
::::