Nibor / Docs / App Hub Book a demo

App Hub: APIs, agents and integrations for each app

Every app is also a backend. The App Hub is the per-app control room: REST API, API keys, MCP for AI agents, integrations, webhooks, users, performance and export.

The tabs

Integrations

The Integrations tab holds one encrypted credential per provider. Four providers are wired directly (Resend for email, Stripe for payments, Twilio for SMS, Slack for messages) and a catalog of further systems can be connected with an API key, a bearer token, basic auth, a header or a query parameter: property-management and lock systems such as KISS, credit checks with UC (client certificate), e-signing with Idura Signatures, and any vendor with an OpenAPI document. Server functions call them through ctx.callIntegration('provider', ...); the platform adds the credential, so no key ever reaches generated code, logs or a tool result. Each entry has a Test button that talks to the vendor once and reports the answer.

Sign-in with BankID is an integration too: connect Idura Verify (issuer, client ID, client secret from your Idura application) and declare appAuth.identityLogin in the app spec (see NAS). The login page then shows Logga in med BankID; the proven personal number is matched to the customer's own record and the session carries that record's email, so the app's row-level security applies unchanged. Staff keep email and password.

REST API

Each app exposes its resources under /_api/apps/<app-id>/invoke/<resource>: list, read, create, update and delete, with the app's row-level security applied. The Hub shows a live index of resources and copy-ready examples.

API keys and scopes

Create keys per integration with explicit scopes (read, write, admin). Keys are shown once and stored hashed; revoke them anytime from the Hub.

Data isolation: one Postgres schema per app

Every current app gets its own Postgres schema — tables keep their natural names (tickets, companies) and cannot collide with any other app's, and row-level security applies inside the schema. Apps created before August 2026 used a shared schema with per-app table prefixes (e.g. bygg_employees); those were migrated to dedicated schemas. If you see both naming styles in older documents, that is the historical reason — isolation today is always per-schema + RLS.

MCP: connect Claude, Cursor or any agent

Nibor speaks Model Context Protocol on two levels. The platform server at POST /_mcp exposes the whole platform: generate complete apps from a prompt (nibor_create_app → poll nibor_generation_status → nibor_deploy_app), edit models and pages, query and modify app data, run read-only SQL, and manage webhooks — authenticated with a Platform API key (plat_…, from Portal → Developers) or a Bearer token, and gated to apps you own or belong to. The Studio chat itself is a tool: nibor_chat sends one message and runs the same agentic turn the Studio runs (poll nibor_generation_status for the reply and the tools that ran; a turn that changed the app leaves a restore point for nibor_restore_version). The chat's own verbs are tools too, with the same definitions: every verb the Studio chat can run (inspect, read and fix pages, add and duplicate models and pages, navigation, components, automations, config, users, brand, email templates, workflows, integrations, webhooks, connectors, database views, the error log, the table check, observe, export, restore) is a nibor_* tool, for example nibor_inspect_app, nibor_read_page, nibor_add_model, nibor_add_page, nibor_fix_page, nibor_seed_data, nibor_manage_integrations, nibor_list_integrations_catalog, nibor_create_connector, nibor_manage_webhooks, nibor_http_fetch, nibor_export_app, nibor_observe, nibor_manage_users and nibor_manage_brand. Publishing stays nibor_deploy_app (it runs the security scan), a whole-app rebuild is nibor_upgrade_app, and clearing data is nibor_delete_data. Writes need the app owner or an org admin; reads need membership. With Claude Code it is one command:

claude mcp add --transport http nibor https://nibor.io/_mcp --header "X-API-Key: <your-plat-key>"

Portal → Developers → MCP also offers downloadable agent-workflow files (Claude skill, AGENTS.md for Codex/OpenCode, a Cursor rule) that teach your AI tool the build-poll-deploy loop and key hygiene.

The per-app server at POST /_api/apps/<app-id>/mcp (or /_mcp/app/<app-id>) scopes an agent to a single app's tables: one tool per operation on each resource, over a hundred for a typical app, gated by the API key's scopes. Example client config:

{
  "mcpServers": {
    "my-nibor-app": {
      "url": "https://nibor.io/_api/apps/<app-id>/mcp",
      "headers": { "Authorization": "Bearer <api-key>" }
    }
  }
}

Server functions and webhooks

Apps with business logic (validations, payments, custom flows) run compiled server functions — compiled automatically when the app is generated or edited. The Hub's Connections tab shows each function's health: compile state, runs and errors over the last 24 hours. Scheduled jobs run automatically once the app is published.

Outbound webhooks (your app notifies other systems)

App Hub → Connections → Webhooks: add a destination URL and the events to subscribe to (* for everything, or globs like contacts.*). On every confirmed record.created / record.updated / record.deleted, Nibor POSTs a JSON payload — signed with your secret as X-Nibor-Signature: sha256=<hex HMAC of the raw body> — and records the delivery status next to the hook. The Test button fires a signed test.delivery event so you can verify your receiver before going live.

Inbound webhooks (other systems notify your app)

Ask the chat: “handle Stripe checkout.session.completed webhooks” — it registers a receiver and compiles the handler. Point the provider at https://nibor.io/_api/apps/<appId>/webhook/<provider>. Signatures are verified (Stripe’s stripe-signature with a replay window; GitHub-style x-hub-signature-256 for others) against a named signing secret; if that secret is declared but not provisioned, the receiver answers 503 until it is — it never processes unverified silently.

Agent webhook (AI events into your app)

App Hub → Agents shows your app’s dedicated webhook URL and its auto-generated secret. External agents sign each POST with X-Agent-Signature: sha256=<hex HMAC>.

Export: take the whole stack

Download your app as a standalone project: compiled frontend, the full component runtime, PostgreSQL schema with row-level security, docker-compose, and the server functions. It runs on your own infrastructure with no connection back to Nibor. This is the same path enterprises use for on-prem deployments.

← Prompt library Workspace →