CRUDBooster API Builder Tutorial: From Quick CRUD to Advanced Workflow

CRUDBooster gives you a fast way to publish APIs without writing each endpoint manually. In this guide, you will build an end-to-end API workflow using the actual API Builder behavior in the package source, including runtime auth, rate limit, caching, and conditional branching.

Why This Tutorial Matters

Official docs currently explain core framework usage very well, but API Builder is not yet covered in detail. This tutorial fills that gap with a practical flow you can reproduce immediately.

Step 1: Start with Quick Mode (Fast Baseline)

From API Builder > Generate New API, choose Quick Mode and select one table. Quick Mode auto-generates 5 endpoints:

• GET /v1/{table}/list
• GET /v1/{table}/detail
• POST /v1/{table}/create
• POST /v1/{table}/update
• POST /v1/{table}/delete

Each endpoint is created with status=active, rate_limit_enabled=true, and rate_limit_rpm=60. This gives you a production-like baseline instantly.

Step 2: Open One Endpoint in Advanced Editor

Go to one generated endpoint and click Edit. You will see a 4-step flow:

• Basic Information
• Define Payload
• Define Process
• Define Output

Basic Information

Set endpoint path, method, description, and traffic controls. You can enable rate limiting and configure requests per minute.

Define Payload

Define payload schema keys, type, required flag, and description. This schema is also used for API test form and OpenAPI generation.

Define Process

This is the core of API Builder. You compose actions with aliases and chain results between actions.

Step 3: Build a Real Process Flow

A common pattern is validation gate + database mutation + external call.

{
  "process_steps": [
    {
      "alias": "check_age",
      "action_type": "condition",
      "condition_logical_operator": "and",
      "condition_rules": [
        { "source_ref": "payload.age", "operator": "<", "value": "18" }
      ],
      "true_actions": [
        {
          "alias": "age_error",
          "action_type": "throw_error",
          "error_message": "Age must be 18+",
          "error_status_code": 422
        }
      ]
    },
    {
      "alias": "create_user",
      "action_type": "insert",
      "target_table": "users",
      "column_mappings": [
        { "column": "name", "source_ref": "payload.name" },
        { "column": "email", "source_ref": "payload.email" }
      ]
    }
  ]
}

Supported action types in runtime are:

• select, insert, update, delete
• call_api (external API request)
• condition (with nested true_actions)
• throw_error

Step 4: Use References Correctly

In mapping and conditions, use these source reference patterns:

• payload.field_name
• action_alias.some_alias
• action_alias.some_alias.field_name
• __manual__ + manual value

You can also use template placeholders in URL/raw SQL contexts, for example {payload.user_id}.

Step 5: Configure Output Mapper

Two output modes are available:

• last_action: returns output from the last executed action.
• custom: map specific outputs from payload/action aliases into your response contract.

Step 6: Secure Runtime with Scoped Tokens

Open Credential / Token tab and generate token with scope, for example /v1/users/* or /v1/*.

Runtime requests require a valid Bearer token:

curl -X POST "https://your-domain.com/api/v1/users/create" \
  -H "Authorization: Bearer cb_xxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"name":"John","email":"john@example.com"}'

If active tokens exist and request has no valid bearer token, runtime returns 401 Unauthorized.

Step 7: Enable Traffic Controls

For each endpoint, you can enable:

• Rate limiting with per-IP request cap per minute.
• Response caching with a 60-second TTL based on method + endpoint + payload hash.

When cache is enabled, successful response includes a cached flag so behavior is observable during tests.

Step 8: Test and Document

Use built-in Test API modal to run endpoint calls quickly. For external consumers, open:

• /cms/api-docs for Swagger UI
• /cms/api-docs/openapi.json for generated OpenAPI spec

Step 9: Monitor with Logs & Metrics

Use the Logs & Metrics tab to monitor:

• Total calls, error rate, average latency, success rate
• Real-time activity log
• Error distribution by endpoint

API request logs are also used to update endpoint-level aggregate stats like avg_response_ms and error_rate_percent.

Production Checklist

• Scope tokens narrowly (avoid universal wildcard for sensitive endpoints).
• Turn on rate limiting for all public-facing APIs.
• Use response cache only for idempotent and read-heavy paths.
• Use throw_error in condition branches for explicit validation feedback.
• Review Logs & Metrics after publish and tune RPM per endpoint.

References

• CRUDBooster Official Docs (index)
• Related article: Laravel API Builder Trend 2026