🗄️ Database

Database shows your app’s data in two halves. The collections are what the app stores. The endpoints are the only ways it can reach that data.

Both are on the same panel, collections first.

Collections

Each collection lists its fields and their types, and relationships between collections are shown on the collections they connect.

Why the schema is read-only here

In an app Ada builds, the shape of the data is declared by the app’s own configuration. This panel draws that configuration, but it writes to the older structure that these apps do not have.

So the controls that would change the shape are not offered:

• Add Collection, and Add Property
• Rename a collection or a property
• Delete a collection or a property
• The collections menu — permissions, Magic Start, Magic Add
• CSV import
• The generated API documentation

Note

These are hidden rather than disabled-with-an-error because each one used to look like it worked. Adding a property wrote nothing the app reads, created no column, and told the generated app nothing. A collection you deleted came back on the next draw, because it was still in the configuration and still answered by every endpoint naming it.

To change the shape of your data, ask Ada. It edits the configuration, regenerates the data layer, and wires the change into the screens that use it.

Records are a different matter — those you can still open and edit.

Endpoints

Below the collections is the Endpoints block, with a count beside the heading.

The only ways this app reaches its data. Anything not listed here is unreachable.

That is worth taking literally. An operation with no endpoint cannot happen, whatever a screen appears to offer.

The block does not appear at all for an app whose collections still answer directly.

Who each endpoint is open to

Every endpoint carries an audience label:

• Anyone — reachable without signing in.
• Signed-in users — any signed-in user.
• Some signed-in users — signed-in users who also pass the endpoint’s own rule.
• Not readable — the audience could not be determined.

If any endpoint is open to anyone, a warning above the list says how many, so it is visible without opening each one.

What each endpoint does

Under the name, one line says what the endpoint does and whose records it touches. The operation is written in plain words — Read, Count or total, Create, Change, Delete, Attach to, Detach from — followed by the scope, with a wider-than-usual scope marked.

Two further lines appear when they apply:

• Only if … — the condition the caller must satisfy.
• Always limited to: … — filters the endpoint applies no matter what the caller asks for.

Example

Example shows the actual request this endpoint answers, so you can see the shape of the call rather than infer it. Hide example closes it again.

Editing and adding

Edit opens the endpoint’s full definition. + New endpoint at the foot of the list adds one.

Because endpoints are the only way in, adding or widening one grants real access. Read the audience label after any edit.

Signing in, renewing and signing out

At the very bottom is a collapsed section: Signing in, renewing and signing out.

These are the platform’s own routes. They are identical in every app and there is nothing to declare or change about them, which is why they are not in the endpoint list — and why they are shown here read-only, so the panel answers “how does this app authenticate” completely.

Five routes are listed, each with a copyable cURL command:

• Sign in — email and password in, a token, refresh token and expiry out.
• Trade the refresh token for a new pair — carries no access token, since the expired one is what the call exists to replace.
• End this session — the refresh token stops working.
• End every session this user has
• The user’s live sessions — one row per session, with device, address and last use.

Note

signUp and me are not in this section. They are ordinary endpoints and appear in the list above with everything you can change about them.