Build APIs and deploy a database

After creating a schema file (.sfn), turn the design into a working service. API Build prepares create, read, update, and delete APIs for every table and shows who can use each address.

You can also connect custom query APIs, static file APIs, and real-time events to the same service.

Before you begin

• Required permission: A user with database permission
• Prerequisite: Create a schema file (.sfn) first.

Open API Build

Select the API Build tab at the top of the schema screen to review the automatically generated APIs for each table.

Automatically generated APIs

Five APIs are generated for each table by default. You can also add custom APIs when needed.

Use Add new API (Custom Endpoint) to define an API with the required query and response shape. Use Add static file API to serve JSON, XML, HTML, image, and binary files from the workspace with the appropriate file type.

Serve a file or folder through an API

1. Select Add static file API.
2. Under Storage space, choose Team space or Personal space.
3. Under Source type, choose Single file or Folder list · file content, then use Choose file or Choose folder to select the source.
4. For a folder, set Allowed extensions and Include subfolders. Leaving the extensions empty includes all file types.
5. Under Response mode, choose whether to show content in the browser (Display in browser) or return it as a file (Download).
6. Review the endpoint permissions, then deploy the schema.

A single-file endpoint returns that file. A folder endpoint creates both a JSON file list and an address that reads content by an item's id. Renaming or moving a file changes its path-based id, so clients should use the latest id or viewUrl from the list response.

Feature endpoints control permissions for service-wide capabilities such as real-time sockets, file and image uploads, and AI responses.

Import real-time events and REST settings

Under Event definitions for the real-time socket, you can define events alone or import a JSON or YAML bundle that also contains the required tables and REST settings.

1. Select Paste AI answer and paste the bundle. You can paste a bundle you prepared yourself in the same format.
2. Choose Merge by name to retain existing events, or Replace all to replace the current event definitions.
3. In Preview, review the events to add, change, or remove and the counts of tables, columns, and REST endpoints to add.
4. Review REST conflicts and any items that were normalized or skipped. Select Overwrite conflicting REST settings only when the existing REST settings must change.
5. Review the server check, fix its errors, and select Apply.

Importing changes the schema currently being edited. The service changes only after you complete Deploy. The server checks the event and REST rules again during deployment and rejects the deployment if they do not pass.

Building APIs beyond CRUD with a custom endpoint

When the 5 auto-generated APIs (list/view/create/update/delete) aren't enough, clicking Add new API (Custom Endpoint) lets you define behavior in much finer detail.

Operation kind

Beyond the 5 basic CRUD actions, the Operation kind dropdown also offers:

Scope is one of Collection (the whole table or multiple records, usually a path without :id), Item (one specific record), or Command (a custom, command-style endpoint that doesn't fit CRUD).

Permissions use the same 3 tiers as the REST API

Custom endpoints use the same permission options as the auto-generated APIs.

Choosing Member + Additional Conditions lets you combine level, team, admin status, and owner (self) conditions — the same way you'd restrict "level 2 or higher" or "sales team only" on an auto-generated REST endpoint, you can apply it to a custom endpoint too.

Writing raw SQL

On the Processing flow tab, Base query has an editor where you write the SQL this endpoint runs. On an auto-generated API, switching Base query to Hand-written SQL opens the same editor.

The REST API list's Processing column also shows an SQL badge marking that this endpoint runs a query you wrote directly. Conditions the auto-generated APIs can't express — like "reject if this member has already created 3 or more rows today" — can only be built with this SQL editor.

Check SQL and parameters

As you type SQL, the browser checks its syntax and the tables and columns in the current schema. If an error or warning includes a line and column, select it to move to that position in the editor. You can also open SQL with errors from the deployment area.

This check does not run the query against your database. After deployment, call the API to verify database-specific functions, access permissions, and results with real data.

The parameter list shows the :name values used in the SQL. The server fills the reserved values :id, :user_id, :nick, and :now. Other values come from the query string for read requests or the request body after input processing for write requests. Missing values become NULL.

Changing request handling with the processing flow

Without writing SQL, you can also add pre-built functions on the Processing flow tab in sequence to change how a request is processed. Functions fall into three stages: Input, Database, and Output.

Configure permissions

Configure access separately for each API. A member here is an existing workspace member account. You do not need to create another sign-in or authentication system because workspace members, levels, and teams are connected directly to API permissions.

Deploy

Enter the deployment information as follows.

1. Database identifier: Enter the logical DB name to use on the deployment server in English.
2. Storage engine mode: Select SQLite3, PostgreSQL, MySQL, or MariaDB. For an external DB, also enter the host, port, DB name, user, and password. MySQL and MariaDB use an InnoDB-based configuration.
3. Under General and Advanced, review the following items.

Select Deploy in the deployment section below the API list to open its settings. This section stays fixed at the bottom of the editor, so it remains visible while you scroll the API list. The first selection does not deploy anything. Review the settings, then select Deploy again to prepare the database and APIs. If you selected a client deployment path, Webspace also creates a sample interface for testing the APIs. Continue with Review the frontend sample to modify the interface.

API request examples

The following examples use the user_profile table.

GET  /api/web/{dbName}/user_profile/list
GET  /api/web/{dbName}/user_profile/view/{id}
POST /api/web/{dbName}/user_profile/create
PUT  /api/web/{dbName}/user_profile/update/{id}
DELETE /api/web/{dbName}/user_profile/delete/{id}

Create (POST) request example:

POST /api/web/{dbName}/user_profile/create
Content-Type: application/json

{
  "email": "user@example.com",
  "is_active": true
}

Read error responses

When a request fails, check its HTTP status and code or errorCode. Codes stay the same across languages: use them to decide whether to request sign-in or retry, and use message for display.

Built-in WebSpace error messages support Korean, English, Japanese, Simplified Chinese, and German. The signed-in account's language takes precedence. If it is absent or unsupported, the server consults the request's Accept-Language header. English is the fallback when neither matches. Do not compare display text in an API integration.

For example, a request requiring sign-in returns these fields:

{
  "code": "WEBSPACE_LOGIN_REQUIRED",
  "errorCode": "WEBSPACE_LOGIN_REQUIRED",
  "message": "Sign in to continue."
}

These are the key fields to inspect, not a complete response example. REST, static-file, and administration APIs may use different envelopes.

• Input validation keeps the existing ok: false and errors list. Check ok even when HTTP status is 200, and use each item's field, code, and message to explain the issue.
• WebSocket failures appear in data within a type: "error" message. The existing routing key is preserved; code and errorCode identify the cause.
• Physical server paths, SQL, and raw internal errors are not returned to users. When operator investigation is needed, provide the time, request path, HTTP status, and error code.

Deployment and overwriting

Overwriting a schema whose database already contains data follows the server deployment policy. Your organization can prohibit it or restrict it to administrators and designated deployment operators. Before changing the structure, review affected columns and APIs and confirm backup and recovery procedures.

Good to Know

• APIs use SetFN sign-in sessions for authentication. Unauthenticated requests are rejected unless the API permission is set to Anyone.
• Changing the schema structure also updates its API endpoints. Check compatibility with existing integrations.
• SQLite3 data is stored in the server's WebSpace storage. External-engine data is stored in the database configured by the administrator.
• Use list filters, sorting, and page sizes only within the query ranges allowed by the server.
• For calls from an external site, also check the administrator's allowed origins and CSP settings.

Related Documents

• Create a schema file (.sfn)
• Build a real-time Gomoku game
• Checking the Frontend Sample
• Performance and scaling
• Get started with WebSpace administration