Run any Skill in Manus with one click

blocks-data-gateway-configuration

Stars0

Forks3

UpdatedJuly 14, 2026 at 19:06

Configure the data model of a SELISE Blocks project through the data service REST admin API (`https://api.seliseblocks.com/data/v4`): create and edit schemas/collections, add or remove properties/fields, add field validation rules (incl. the AI regex assistant), set schema/field access levels and data-access policies, and RELOAD so changes go live in the runtime gateway. Also covers mock/sample data inventory + deletion and schema-exchange (export/import a data model between projects). Use whenever the user wants to define, edit, secure, validate, reload, copy, or reset the DATA MODEL of a Blocks project — 'add a field to my schema', 'make this collection public', 'validate the email field', 'reload the schema', 'clone my schemas to staging', 'wipe the demo data'. This is the admin/portal side; for running GraphQL create/read/update/delete against the resulting schemas use blocks-data-gateway-crud, and for file/DMS storage use blocks-data-storage.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

SELISEdigitalplatforms

SELISEdigitalplatforms/blocks-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

6 files

SKILL.md

readonly

More from this repository

same repository

blocks-onboarding

SELISEdigitalplatforms/blocks-skills

Onboard a user into SELISE Blocks before any other Blocks skill can run — detect their current state and get them to a working setup: no Blocks account yet (guide signup at https://os.seliseblocks.com), account but no project (ask what they want to build and create the project via API — suggest a dev-only default), project but no credentials file (have the user create the `.env`), or everything present (verify and hand off). Also covers adding more environments (test/stg/uat/prod/…) to an existing project and deleting environments, via API. Use whenever a user is new to Blocks, asks how to get started / sign up / create a project / add or remove an environment, or when a prerequisite fails in another skill — missing `.env` or `BLOCKS_USERNAME`, `auth-login` returns 401/invalid credentials, or `Project/Gets` returns no projects. Only SIGNUP is portal-only (browser, not API); project and environment management is scriptable. Run the preflight here whenever the user's account/project state is unknown.

2026-07-140

blocks-data-gateway-crud

SELISEdigitalplatforms/blocks-skills

Implement GraphQL create/read/update/delete against a SELISE Blocks project's runtime data gateway (`POST https://api.seliseblocks.com/data/v4/gateway`). Covers discovering a schema's auto-generated operation names, writing the query (`get<Collection>` with where/paging/order), insert/update/delete mutations (and insertMany/updateMany/deleteMany), the result + ActionResponse shapes, and wiring it all into a frontend (React 19 / TanStack Query hooks). Use whenever the user wants to READ or WRITE actual data/records through a Blocks schema from an app or script — 'fetch products from my Blocks collection', 'insert a record via the gateway', 'write the update mutation', 'CRUD hooks for my schema', 'why does getOrders not exist on Query'. The schema must already be created + reloaded via blocks-data-gateway-configuration; for file storage use blocks-data-storage.

2026-07-140

blocks-data-storage

SELISEdigitalplatforms/blocks-skills

Store and serve files on a SELISE Blocks project via the data service's DMS (document management system) — the `/data/v4/Files/*` API. Covers the pre-signed-URL upload (get upload URL → PUT the file binary to storage, with the Azure `x-ms-blob-type` header when needed → get download URL), downloading/listing files, folders (create/list/delete), tags/metadata/versions, and deleting files. Use whenever the user wants to upload, download, browse, organize, or delete FILES/attachments/documents/images on Blocks — 'upload a PDF and get a link', 'attach an image to a record', 'let users download this file', 'create a folder and list its contents', 'get a presigned upload URL'. This is separate from the data model: to define schemas use blocks-data-gateway-configuration, and to CRUD records use blocks-data-gateway-crud (store a file here, keep its fileId in a schema field there).

2026-07-140

blocks-frontend-local-https

SELISEdigitalplatforms/blocks-skills

Run a frontend React app locally over HTTPS on its real project domain, using a locally-generated SSL certificate — required so SELISE Blocks SSO/OIDC login works, because the auth callback sets a Secure, domain-scoped session cookie that the browser rejects on plain http://localhost. The skill: discovers the project's domain from /os/v4/Project/Gets (projects[].applications[].domain, filtered by environment) or asks the user, adds a hosts entry mapping that domain to 127.0.0.1, generates a self-signed local cert for it with openssl (and trusts it), configures the dev server (Vite/CRA/Next) to serve https on that domain + port, and runs it at https://your.domain.com:PORT. Use whenever the user needs to run/test a Blocks app locally over HTTPS, fix 'SSO cookie not set / session lost on localhost', set up a local dev cert, serve a custom domain locally, or make the OIDC redirect work in local dev. A real/owned domain name is required to issue the cert — you cannot make one without a domain.

2026-07-140

blocks-iam-sso-oidc-configuration

SELISEdigitalplatforms/blocks-skills

Configure SSO / OIDC login for a SELISE Blocks project via the IAM admin API (`https://api.seliseblocks.com/iam/v4`): ensure a `blocks-oidc` identity provider exists, creating the OIDC client (`/oidc-clients`) and the identity provider (`/auth/identity-providers`) if they don't. Use whenever the user wants to SET UP / enable / configure single sign-on, OIDC, or an identity provider for their Blocks app — 'enable SSO for my project', 'configure OIDC login', 'register an OIDC client', 'add a blocks-oidc identity provider', 'set up authorization-code login on Blocks'. This is the admin/portal side and requires impersonating into the project first; once configured, wire the login into the app with blocks-iam-sso-oidc-implementation. If the app invites users via the portal or API, also wire an optional /activate page (blocks-iam-account) — not required for SSO login itself.

2026-07-140

blocks-iam-sso-oidc-implementation

SELISEdigitalplatforms/blocks-skills

Implement SELISE Blocks SSO / OIDC login in a frontend codebase — the authorization-code flow via `/iam/v4/idp/initiate` → redirect to `iam.seliseblocks.com` → `/iam/v4/idp/callback` (which sets the session cookie). Already-activated users log in through this flow directly. Optionally wire `/activate` (blocks-iam-account) only when the app invites inactive users via the portal or API who must activate before their first login. Also covers renewing the browser session via `POST /iam/v4/oidc/token`. Use whenever the user wants to ADD login/sign-in to a Blocks app, wire up SSO/OIDC on the client, build a login button, handle the OIDC redirect/callback, implement account activation for invited users, or keep the session alive after SSO. Do NOT implement username/password login directly — Blocks login goes through this hosted authorization-code flow. The project's OIDC provider must already be configured (blocks-iam-sso-oidc-configuration); this skill is the app-side wiring.

2026-07-140

name

blocks-data-gateway-configuration

description

Blocks Data — Gateway Configuration

The data service (https://api.seliseblocks.com/data/v4) is the admin surface where a Blocks project's data model lives. You use it to shape schemas and fields, attach validation and access rules, then reload so the runtime GraphQL gateway reflects them. It also handles mock-data cleanup and copying a data model between projects.

This is the configuration half. Once a schema is live here, the blocks-data-gateway-crud skill runs GraphQL CRUD against it. File storage (DMS) is blocks-data-storage.

Auth & keys — start here (the #1 thing people get wrong)

Prerequisites: a Blocks account, at least one project, and a .env with BLOCKS_API_URL, BLOCKS_USERNAME, BLOCKS_PASSWORD. Missing or unknown — no .env, auth-login 401, empty Project/Gets — run the blocks-onboarding skill first.

Configuration happens inside a project/tenant, so you first obtain an impersonated, project-scoped token. This is the shared "initial steps" every Blocks config skill runs — flows/get-into-project.md (login → list projects → impersonate). It gives you three values:

ACCOUNT_TENANT — bootstrap/account tenant id (the login token's tenant_id claim). Used as x-blocks-key on every configuration call (data, IAM, storage, localization) after impersonation.
PTENANT — the target project's tenant id (from Project/Gets, or user-provided) → projectKey in bodies (and equivalent query params). Not x-blocks-key on configuration calls.
PTOK — the impersonated access token valid for the project → Authorization: Bearer.

Every configuration call therefore carries:

x-blocks-key: <ACCOUNT_TENANT>      # root tenant id — never PTENANT here
Authorization: Bearer <PTOK>

…and puts projectKey: <PTENANT> in the body. Strict rule: for configuring data/IAM/storage/localization, x-blocks-key is always the root tenant (ACCOUNT_TENANT); PTENANT scopes the project via projectKey only. 401 / session_expired → expired PTOK; renew via POST /iam/v4/auth-token then re-impersonate (see get-into-project).

⚠️ Do not swap the keys. Configuration happens after impersonation — PTOK carries project scope, but the x-blocks-key header stays ACCOUNT_TENANT. Sending PTENANT as x-blocks-key on admin/config calls is wrong. projectKey in bodies is always PTENANT (same as targeted_tenant_id). Not impersonated yet? Run get-into-project first.

URL convention

REST base: https://api.seliseblocks.com/data/v4 — no /api/ prefix. The swagger advertises /api/... but that path serves the portal SPA, not the API. Use /data/v4/schemas/define, not /data/v4/api/schemas/define.

What's where

I need to…	Go to
Get an impersonated project token (do this first)	flows/get-into-project.md
Create a schema, add/edit fields, add validation, set access, reload	flows/configure-schema.md
Inventory or delete mock/sample data	flows/manage-mock-data.md
Copy a data model from one project to another	flows/schema-exchange.md
Configure schema admin from a React app	references/react.md
Run GraphQL CRUD against the live schemas	blocks-data-gateway-crud
Store/serve files (DMS)	blocks-data-storage

The config → runtime bridge

Every entity schema (schemaType: 1) carries two fields in GET /schemas that name its generated GraphQL surface, so the CRUD skill never has to guess:

querySchema (e.g. "Products") → read query is get<querySchema> → getProducts.
mutationSchemas (e.g. ["insertProduct","updateProduct","deleteProduct"]) → the exact mutation names (plus insertMany…/updateMany…/deleteMany…).

Hand these to blocks-data-gateway-crud after a reload.

Key concepts (verified live)

Schema — one collection: { schemaName, collectionName, schemaType, fields[] }. schemaType: 1 = entity (gets a collection + GraphQL CRUD). collectionName follows the project's collectionNamePattern (default sb_{SchemaName}s, from GET /configurations).
Field — { name, type, isArray, isPIIData, isUniqueData, description }. type is a string scalar name ("String", "Int", "Long", "Float", "Boolean", "DateTime", or a nested schema name). Set isPIIData: true deliberately for personal data. Field names become the PascalCase GraphQL field names.
Never define system/default fields — Blocks auto-adds ItemId, CreatedDate, CreatedBy, LastUpdatedDate, LastUpdatedBy, Language, OrganizationId, and Tags to every entity schema. Define only your own domain fields; adding these yourself conflicts with the platform-managed ones.
Reload — POST /schema-configurations/reload. Schema/field/validation/access edits are staged until this succeeds (data: true); the gateway does not see them before. Every config flow ends here. Check pending edits with GET /schemas/unadapted-change-logs.
Access & policies — each schema (and optionally field) has read/write/edit/delete access levels; Custom levels are driven by rule-based data-access policies. See configure-schema.md step 5.
Mock data — seeded sample records; the API inventories and deletes them (generation is portal-only). See manage-mock-data.md.
Schema exchange — async export/import of a whole data model between projects, correlated by messageCoRelationId, result delivered via a notification from the OS service (no skill in this repo covers notifications yet — verify the result live or in the portal). See schema-exchange.md.

Gotchas

Reload or it didn't happen. New/edited schemas are invisible to the gateway (and to blocks-data-gateway-crud) until reload succeeds.
x-blocks-key = ACCOUNT_TENANT on configuration calls; projectKey = PTENANT. Never send PTENANT as x-blocks-key when configuring schemas — the impersonated token scopes the project.
List params are PascalCase — ProjectKey, SchemaName, PageNo, PageSize, Keyword, SortBy, SortDescending.
Unnamed int enums. schemaType, SchemaAccessLevel, validation type, policy enums, exportOption are numeric in the swagger with no member names. The mappings in the flows are from legacy docs — verify against the portal UI before scripting bulk changes.