Interface IObject

Additional properties' info.

The additionalProperties means the type schema info of the additional properties that are not listed in the properties.

If the value is false, it means that the additional properties are not specified. Otherwise, if the value is IJsonSchema type, it means that the additional properties must follow the type schema info.

• false: No additional properties
• IJsonSchema: Record<string, T>

API documentation for the type.

This is the standard OpenAPI description field that will be displayed in Swagger UI, SDK documentation, and other API documentation tools. Focus on explaining the type from an API consumer's perspective.

The description SHOULD be organized into MULTIPLE PARAGRAPHS (separated by line breaks) covering:

• WHAT: The purpose and business meaning of the type
• WHY: When and why this type is used
• Relationships: Connections to other entities in the system
• Constraints: Validation rules visible to API consumers

Important Notes

• Reference the corresponding database schema table's documentation to maintain consistency
• Do NOT include implementation details here (use x-autobe-specification for object types)
• Keep the language accessible to API consumers who may not know the internal implementation

MUST be written in English. Never use other languages.

Properties of the object.

The properties means a list of key-value pairs of the object's regular properties. The key is the name of the regular property, and the value is the type schema info.

IMPORTANT: Each property in this object MUST have a detailed description that references and aligns with the description comments from the corresponding database schema column.

If you need additional properties that is represented by dynamic key, you can use the additionalProperties instead.

List of key values of the required properties.

The required means a list of the key values of the required properties. If some property key is not listed in the required list, it means that property is optional. Otherwise some property key exists in the required list, it means that the property must be filled.

Below is an example of the properties and required.

interface SomeObject {
  id: string;
  email: string;
  name?: string;
}
Copy

As you can see, id and email properties are required, so that they are listed in the required list.

{
  "type": "object",
  "properties": {
    "id": { "type": "string" },
    "email": { "type": "string" },
    "name": { "type": "string" }
  },
  "required": ["id", "email"]
}
Copy

Discriminator value of the type.

CRITICAL: This MUST be a SINGLE string value, NOT an array. The type field identifies the JSON Schema type and must be exactly one of: "boolean", "integer", "number", "string", "array", "object", or "null".

❌ INCORRECT: type: ["string", "null"] // This is WRONG! ✅ CORRECT: type: "string" // For nullable string, use oneOf instead

If you need to express a nullable type (e.g., string | null), you MUST use the IOneOf structure:

{
  "oneOf": [{ "type": "string" }, { "type": "null" }]
}
Copy

NEVER use array notation in the type field. The type field is a discriminator that accepts only a single string value.

Target database table that this DTO object represents.

Establishes a direct link between this DTO schema and a specific database table. This mapping is critical for:

• Property validation: Verifying DTO properties exist in the table
• Code generation: Generating correct database queries and selects
• Type consistency: Ensuring DTO structure aligns with database schema

When to Set a Table Name

Set this to a valid table name when the DTO directly represents or derives from a specific database table:

• Entity types (IUser, IOrder): Map to their primary table
• Summary types (IUser.ISummary): Map to the same table as parent
• Create/Update DTOs (IUser.ICreate): Map to the target table

When to Set null

Set this to null when the DTO has no direct database table mapping. Common cases include:

1. Composite/Aggregated types: DTOs that combine data from multiple tables (e.g., IDashboardSummary aggregating user, order, and product statistics)
2. Request parameter types: Search filters, pagination options, sorting criteria (e.g., IUser.IRequest, IPageInfo)
3. Computed result types: DTOs representing calculation outputs (e.g., IRevenueReport, IAnalyticsResult)
4. Wrapper types: Container types for API responses (e.g., IPage<T>, IApiResponse<T>)
5. Pure business logic types: DTOs born from requirements, not database structure (e.g., ICheckoutSession, IPaymentIntent)

Critical Requirement When null

When this field is null, the x-autobe-specification field (in IJsonSchemaDescriptive.IObject) MUST contain detailed implementation instructions:

• Source tables and columns involved
• Join conditions between tables
• Aggregation formulas (SUM, COUNT, AVG, etc.)
• Business rules and transformation logic
• Edge cases (nulls, empty sets, defaults)

CRITICAL: When set, the table name MUST be an actually existing model name from the loaded database schema. Never guess or invent schema names. Using non-existent schema names causes compilation failures and pipeline breakdown.

Implementation specification for this type.

This is an AutoBE-internal field (not exposed in standard OpenAPI output) that provides detailed implementation guidance for downstream agents (Realize Agent, Test Agent, etc.).

Include HOW this type should be implemented:

• Source database tables (primary table and joined tables)
• Overall query strategy (joins, filters, grouping)
• Aggregation formulas if applicable (SUM, COUNT, AVG, etc.)
• Business rules and transformation logic
• Edge cases (nulls, empty sets, defaults)

This field is especially critical when x-autobe-database-schema is null (for composite, computed, or request parameter types), as it provides the only guidance for implementing data retrieval or computation logic.

MUST be written in English. Never use other languages.