API & Datasets: Pull Configuration, Explore Data

This section covers three things: how your local api.ts gets generated, what datasets, fields, and operations are available on the platform, and how to maintain a small amount of dataset metadata safely. Prerequisites: you are logged in, and the current App Code is correct (see Configuration).

Why api pull comes first

The dataset aliases and request wrappers used in your frontend typically come from the project's API directory (defaults to ./src/api/, configurable via apiDir). When this falls out of sync with the platform, you may see issues like "alias not found" or "list request failed." It's a good habit to pull in these scenarios:

• Right after joining a project or running project init
• After adding, removing, or modifying datasets or models on the platform
• After switching the current app or App Code

Command:

rabetbase api pull

Specify an output directory:

rabetbase api pull --output ./src/api

After pulling, you'll have a local model list aligned with the current App. Downstream commands like codegen and dataset --alias rely on these aliases.

List all models (datasets) under the current application

When you want a quick look in the terminal without opening files:

rabetbase api list

In multi-app mode, models are listed per App based on your configuration (output format can be changed with --format json / pretty / compress).

Read-only dataset exploration

List datasets (supports server-side filtering, no need to pull everything):

rabetbase dataset list
rabetbase dataset list --name order
rabetbase dataset list --code <32-digit-code>
rabetbase dataset list --source DB_TABLE
rabetbase dataset list --source METADATA

By default, dataset list returns DO V2 datasets in the current app, including both DB_TABLE and METADATA. The result is a lightweight list: it includes id, name, code, source, and table or field summaries when the list API provides them. Use dataset detail for full fields, operations, and related pages.

Filter by source with --source:

Goal	Command
Database-backed datasets only	rabetbase dataset list --source DB_TABLE
Metadata datasets only	rabetbase dataset list --source METADATA

Use DB_TABLE datasets for custom SQL and SQL schema validation. METADATA datasets do not have physical table context; they are useful for page generation, relationship checks, and other platform metadata workflows. If you need live business rows, switch to runtime lovrabet data filter|getOne.

View full details of a specific dataset (fields, metadata, etc.):

rabetbase dataset detail --code <32-digit-code>

If you've already run api pull, you can use an alias instead of the long code:

rabetbase dataset detail --alias order

See which operations a dataset supports (filter, getOne, create, etc.):

rabetbase dataset operations --alias order
rabetbase dataset operations --alias order --operation filter

Adding --operation shows the parameter definitions for that operation, which is useful when writing BFF scripts or generating code.

Explore relationships between tables

Before writing cross-table queries, complex SQL, or having AI write scripts for you, understanding table relationships can save a lot of rework:

rabetbase dataset links

Filter by database:

rabetbase dataset links --db <database-name-or-ID>

The output includes fields, primary/foreign keys, and association types between datasets. Add --verbose for the raw response.

Controlled Dataset Metadata Maintenance

The commands below modify platform dataset metadata. Preview with --dry-run first, then review before / after and the selector before executing.

Safe rename: dataset rename

# Preview only
rabetbase dataset rename --code <datasetCode> --name "New Name" --expect-name "Current Name" --dry-run

# Execute after review
rabetbase dataset rename --code <datasetCode> --name "New Name" --expect-name "Current Name"

--expect-name checks the current name and aborts if it does not match.

Patch field display properties: dataset field-update

rabetbase dataset field-update \
  --code <datasetCode> \
  --field customerName \
  --patch-json '{"displayName":"Customer Name","required":true}' \
  --expect-json '{"displayName":"Customer"}' \
  --dry-run

Allowed patch keys are doType, displayName, description, options, required, datetimeFormat, defaultAggregation, and chartRole. Structural fields such as id, name, dbFieldName, tableName, and pkField are forbidden.

Patch top-level extend: dataset extend-update

rabetbase dataset extend-update \
  --code <datasetCode> \
  --patch-json '{"businessGroup":"finance"}' \
  --expect-json '{"businessGroup":"sales"}' \
  --dry-run

The current command only exposes businessGroup for controlled maintenance.

Delete dataset metadata: dataset delete

# Preview by code
rabetbase dataset delete --code <datasetCode> --dry-run

# Preview bulk deletion by database connection and lock the expected count
rabetbase dataset delete --dbid <dbId> --expected-count 3 --dry-run

# Real deletion: high-risk confirmation plus --confirm
rabetbase dataset delete --code <datasetCode> --confirm --yes

dataset delete removes platform dataset metadata and related page / menu records. It does not delete physical databases or tables. It is high-risk-write; non-interactive execution needs --yes, and real deletion also requires --confirm.

Generate API documentation (optional)

To export API documentation for the current datasets (default directory and options are listed in rabetbase api doc --help):

rabetbase api doc
rabetbase api doc --datasetcode ds1,ds2

This is useful for sharing with teammates or keeping records. It does not affect your day-to-day development workflow.

---

Summary

• api pull: Keep your local API configuration in sync with the platform.
• api list: Quickly scan models from the terminal.
• dataset list / detail / operations: Explore datasets from summary to detail. Use --source DB_TABLE or --source METADATA when you need one source type only.
• dataset links: View table and dataset relationships. Worth running before writing SQL or BFF scripts.
• dataset rename / field-update / extend-update / delete: Controlled dataset metadata maintenance. Preview first, then execute.

Next: To write platform-hosted custom SQL, read Custom SQL: From Authoring to Execution.