Models & Fields

Models are the foundation of your API. They define the structure and types of data your API will handle.

What Are Models?

A model represents an entity in your application—like a User, Product, or Post. Each model contains fields that describe the properties of that entity.

Example:

A User model might have fields like name, email, and age. Each field has a specific type and optional validation rules.

Creating a Model

  1. From your dashboard, click the "New Model" button
  2. Enter a model name (use singular form, e.g., "User" not "Users")
  3. Add fields one by one with their types and validation
  4. Save your model

Model Naming Best Practices:

  • Use singular nouns (User, Product, Post)
  • Use PascalCase (ProductCategory, not product_category)
  • Be descriptive but concise (UserProfile is better than UP)

Field Types

apibld supports 11 different field types to match your data needs. Each type has specific validation and generation rules.

String- Text up to 255 characters

General purpose text field. Perfect for names, titles, labels, etc.

Validation Options:

  • • Min length (e.g., minimum 3 characters)
  • • Max length (e.g., maximum 100 characters)
  • • Required field
  • • Unique values only
  • • Pattern matching (regex)

Example Mock Data:

"firstName": "Emma", "productName": "Wireless Headphones"

Text- Long-form text content

For longer content like descriptions, articles, or comments.

Validation Options:

  • • Min length
  • • Max length
  • • Required field

Example Mock Data:

"description": "This is a long description with multiple sentences..."

Number- Integer or decimal numbers

Numeric values for quantities, ages, prices, ratings, etc.

Validation Options:

  • • Min value (e.g., minimum 0)
  • • Max value (e.g., maximum 100)
  • • Required field
  • • Integer only (no decimals)

Example Mock Data:

"age": 28, "price": 49.99, "quantity": 150

Boolean- True or false values

Binary states like active/inactive, published/draft, enabled/disabled.

Validation Options:

  • • Default value (true or false)
  • • Required field

Example Mock Data:

"isActive": true, "published": false

Email- Valid email addresses

Automatically validates email format (user@domain.com).

Validation Options:

  • • Required field
  • • Unique values only

Example Mock Data:

"email": "john.doe@example.com"

URL- Valid web addresses

For website links, image URLs, or any web resource.

Validation Options:

  • • Required field
  • • Unique values only

Example Mock Data:

"website": "https://example.com", "avatar": "https://example.com/image.jpg"

Date- Date without time (YYYY-MM-DD)

For birthdays, deadlines, or any date-only values.

Validation Options:

  • • Min date (e.g., not before 1900-01-01)
  • • Max date (e.g., not after today)
  • • Required field

Example Mock Data:

"birthDate": "1995-06-15", "deadline": "2024-12-31"

DateTime- Date with time (ISO 8601)

Full timestamp for events, creation dates, or scheduled times.

Validation Options:

  • • Min datetime
  • • Max datetime
  • • Required field
  • • Auto-set to current time

Example Mock Data:

"createdAt": "2024-01-15T10:30:00Z"

UUID- Universally unique identifiers

Automatically generated unique IDs, perfect for primary keys.

Validation Options:

  • • Auto-generated (v4)
  • • Always unique

Example Mock Data:

"id": "a1b2c3d4-e5f6-7g8h-9i0j-k1l2m3n4o5p6"

JSON- Structured JSON data

For complex nested data structures, metadata, or configuration objects.

Validation Options:

  • • Valid JSON format
  • • Required field

Example Mock Data:

"metadata": { "color": "blue", "size": "large" }

Enum- Predefined list of values

Restrict values to a specific set of options (e.g., status: pending, active, completed).

Validation Options:

  • • Define allowed values (comma-separated)
  • • Default value
  • • Required field

Example Mock Data:

"status": "active", "role": "admin"

Validation Rules

Add validation rules to ensure your data meets specific requirements. Validation is enforced when creating or updating records via the API.

RuleDescriptionApplies To
RequiredField must have a valueAll types
UniqueNo duplicate values allowedString, Email, Number, UUID
Min LengthMinimum character countString, Text
Max LengthMaximum character countString, Text
Min ValueMinimum numeric valueNumber
Max ValueMaximum numeric valueNumber
PatternMust match regex patternString

Best Practices

1. Choose the Right Field Type

Use specific types (Email, URL, UUID) instead of generic String when possible. This ensures better validation and more realistic mock data.

✓ Good: userEmail field with Email type

✗ Bad: userEmail field with String type

2. Add Validation Rules

Protect data integrity with appropriate validation. Mark important fields as required and set reasonable constraints.

Example: email (required, unique), age (min: 0, max: 120)

3. Use Descriptive Field Names

Use clear, consistent naming (camelCase recommended). Avoid abbreviations unless widely understood.

✓ Good: firstName, emailAddress

✗ Bad: fn, eml_addr

4. Keep Models Focused

Each model should represent one entity. Use relationships to connect related data instead of cramming everything into one model.

✓ Good: User model + Address model (related)

✗ Bad: User model with 10+ address fields

Next: Create Relationships

Now that you understand models and fields, learn how to connect models together with relationships.

Learn About Relationships →