Data Schema

This section details the data schema used in the Verifiet API. Understanding the structure of the data returned and required by the API is essential for effective integration and data management.

1. Schema

• Description: Represents the schema based on customer preference.
• Fields:
  • schema_id: string
    • Description: A unique identifier for the schema.
    • Example: "UUID-1234-abcd"
  • name: string
    • Description: The name of the schema.
    • Example: "Customer Schema"
  • type: string
    • Description: Type of the schema (e.g., local, unified).
    • Allowed Values: "local", "unified"
    • Example: "unified"
  • status: string
    • Description: The current status of the schema.
    • Allowed Values: "active", "inactive", "deprecated"
    • Example: "active"
  • created_at: date
    • Description: The date the schema was created in the system.
    • Example: "2024-08-09"
  • updated_at: date
    • Description: The date the schema was last updated.
    • Example: "2024-08-10"

2. Monitoring Schema

• Description: Provides details about the monitoring status and any alerts related to a schema.
• Fields:
  • monitoring_id: string
    • Description: A unique identifier for the monitoring schema.
    • Example: "monitor-5678-efgh"
  • schema_id: string
    • Description: The identifier of the schema this monitoring relates to.
    • Example: "UUID-1234-abcd"
  • alerts: array
    • Description: A list of alerts triggered during monitoring.
    • Items:
      • alert_id: string
        • Description: A unique identifier for the alert.
        • Example: "alert-9012-ijkl"
      • alert_type: string
        • Description: Type of the alert.
        • Allowed Values: "sanction", "watchlist", "adverse_media"
        • Example: "sanction"
      • severity: string
        • Description: The severity level of the alert.
        • Allowed Values: "low", "medium", "high"
        • Example: "high"
      • description: string
        • Description: A brief description of the alert.
        • Example: "Schema found on watchlist."
  • generated_at: datetime
    • Description: The date and time the monitoring was generated.
    • Example: "2024-08-09T12:34:56Z"

3. Onboarding Schema

• Description: Represents a request to onboard a new schema into the system.
• Fields:
  • onboarding_id: string
    • Description: A unique identifier for the onboarding schema.
    • Example: "onboard-3456-mnop"
  • schema: object
    • Description: The schema object to be onboarded.
    • Fields:
      • name: string
        • Description: The name of the schema.
        • Example: "Customer Schema"
      • type: string
        • Description: Type of the schema (e.g., local, unified).
        • Allowed Values: "local", "unified"
        • Example: "unified"
      • address: string
        • Description: The official address of the schema.
        • Example: "123 Main St, Anytown, USA"
  • submitted_at: datetime
    • Description: The date and time the onboarding request was submitted.
    • Example: "2024-08-08T11:22:33Z"
  • status: string
    • Description: The current status of the onboarding request.
    • Allowed Values: "pending", "approved", "rejected"
    • Example: "pending"

4. Error Response

• Description: Standard format for error responses from the API.
• Fields:
  • error_code: string
    • Description: A unique code representing the type of error.
    • Example: "400_BAD_REQUEST"
  • message: string
    • Description: A human-readable message describing the error.
    • Example: "Invalid schema type provided."
  • details: object (optional)
    • Description: Additional details about the error, such as invalid fields or parameters.
    • Fields:
      • field: string
        • Description: The name of the field that caused the error.
        • Example: "type"
      • issue: string
        • Description: The specific issue with the field.
        • Example: "Provided value is not an allowed type."

Best Practices

• Use Schema Validation: Ensure that your data conforms to the schema before making API requests. This helps prevent errors and ensures smooth operation.
• Handle Error Responses: Implement error handling in your application to gracefully handle any issues related to data schema mismatches.
• Stay Updated: Keep an eye on any updates to the schema in future API versions to ensure compatibility.

Conclusion

The data schema defines the structure of the data exchanged between your application and the Verifiet API. Understanding and adhering to this schema is crucial for successful integration and error-free operation.

For further details or if you encounter any issues, please refer to our API documentation or reach out to our support team.