Skapi

Appearance

Project Settings ​

Go to your project page and click on the Project Settings menu.

On this page, you can configure settings for your project. The button that deletes the project is at the bottom of the page. See Deleting a Project.

Only the project owner can change these

Every setting on this page belongs to the project owner's Skapi account, and to Skapi staff when you ask Skapi for help. An admin of your project, access group 99 included, is refused with INVALID_REQUEST and Only the project owner can change project settings.

Project Name ​

You can set the project name in your project settings.

The project name can be used to identify your project in the My Projects page, and also can be used to replace Automated E-Mail's placeholders.

CORS ​

In your project settings, you can set the CORS setting to allow the request from the specific domain.

When left empty, the CORS setting will be set to * by default. Otherwise, you can set the CORS setting to the specific domain, for example, https://example.com. You can also set multiple domains by separating them with a comma, for example, https://example.com,https://example2.com.

When the CORS setting is configured, requests from other domains will be blocked.

In production, it is recommended to set the CORS setting to the specific domain to prevent unauthorized access to your project.

Secret Key ​

Skapi provides API bridge to your custom APIs.

For example, you might have your own external server that you want your users to connect to.

You can set your own secret key to protect your own APIs from unauthorized access.

For more information, refer secure post request to your custom APIs.

Disable/Enable ​

You can disable your project temporarily from the project dashboard.

This is useful when you need to go under maintainance while temporarily blocking the access to your project without losing the data. When you disable your project, all the requests to your project will be blocked, and the project will be shown as disabled in the My Projects page.

WARNING

Disabling your project will not pause your subscription. You will still be charged for the project even when it is disabled.

Allow Signup ​

You can prevent user signup by turning off this option. This setting will prevent anyone to signup or prevent anyone from removing their account in your project.

If this option is turned off, only the admin can create, disable user accounts from the Users page. This is useful when you want to create a private project for a specific group of users.

Prevent Inquiry ​

You can prevent users from sending inquiries to your project by turning off this option.

This is useful when you are not planning to use the sendInquiry() method, and want to prevent spam.

Require Login ​

When this is on, database reads are refused to a visitor who is not signed in.

The SDK refuses them first: getRecords(), getTables(), getTags(), getIndexes() and getUniqueId() throw REQUIRE_LOGIN from a session with no signed-in user. Signed-in users are unaffected.

The four metadata listings are enforced on the server as well. getTables(), getTags(), getIndexes() and getUniqueId() are refused with INVALID_REQUEST when the request arrives with no signed-in user, so a direct API call or a script is refused too. A project that has never set this option counts as on, which is the same default every client already receives as conf.require_login.

WARNING

An integration that reads table, tag, index or unique ID metadata without signing a user in gets an error while this option is on. Turn this option off if that is what you intend.

It is returned to every client as conf.require_login on getConnectionInfo(), so a page can tell before any login whether it should show its own sign-in screen first.

For the records themselves this is still a guard rail, not an access control. Records in access_group: 0 remain readable by anyone calling the API directly, whether or not this setting is on: only the SDK refuses getRecords(). What it prevents is your own app leaking public records through a signed-out page by accident. If data must not be readable without an account, do not store it in access group 0 - use authorized, private, or a higher group.

What a signed-in caller still sees ​

This setting decides whether a caller reads the metadata, not how much of it they read, and only getTables() filters its answer by the caller.

  • getTables() lists every table name in the project, whatever access group the records inside it live in. Its per access group record counters are filtered: the public counter for everyone, the counters up to and including the caller's own access group for a signed-in user, and the private and admin counters for admins and the project owner. number_of_records and size stay totals over every group.
  • getTags() and getIndexes() are not filtered by access group at all, and cannot be: a tag row and an index row are stored keyed by table name with the access group left out of the key, so one row aggregates every group. Any caller allowed to read those listings sees the project's whole tag and index vocabulary, and record counts, sums and averages spanning every access group, including values only private or admin records contributed.
  • getUniqueId() is not filtered either. Called with no unique_id it lists every unique ID in the project and the record ID each one maps to.

The records behind all of this stay gated: fetching one still goes through the usual access group checks. What these listings expose is the shape of the database, so treat a table, tag, index or unique ID name as visible to every signed-in user, and do not encode anything sensitive in one.

It is also unrelated to anonymous writes: whether users without an account may create records is governed separately, and access group 0 is the only group they could ever write to.

Freeze Database ​

You can freeze your database to prevent write operations by non-admin users.

When the database is frozen, every user below access group 90 is blocked from performing write operations. Only read operations will be allowed. They are refused with Database is frozen. Write access is denied for this user., and on a delete with Database is frozen. Delete access is denied for this user.

Admins (access groups 90 ~ 99) and the project owner still write as usual, so a frozen project stays manageable: they upload, update and delete records and files while it is frozen. See Admin Permissions.