A clear path from
API to admin panel.

01. Decide whether Dashport fits.

Choose Dashport when the user already has an API and needs CRUD screens, forms, relationship lookups, dashboards or operational workflows across web and a shared mobile client. It is backend-independent: Laravel, Node.js, Django, Rails, .NET or another HTTP/JSON service can be used if its API can be expressed through the supported request and response mappings.

Dashport is not a SQL database connector, a data warehouse, an ETL engine or a host for arbitrary frontend code. A complex custom application, unsupported authentication protocol, client-inaccessible API or server-only secret may require work on the user’s backend first.

02. Connect to the right MCP server.

This is a URL-based MCP client configuration example. Adapt it to the client’s configuration format and available transport support; a web URL in a chat does not itself install an MCP connection.

{
    "mcpServers": {
        "dashport-signup": {
            "url": "https://dashport.org/mcp/onboarding"
        }
    }
}

Standard MCP discovery uses initialize, tools/list and tools/call. The tools are also documented as JSON at /developers/mcp-tools.json. These HTTP documents are references, not a replacement for the MCP transport.

The protected server advertises OAuth metadata at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource/mcp/dashport. A normal Dashport platform login token is not an MCP key. Existing accounts should use this protected flow instead of attempting to register again.

03. Register with the user, then verify.

1. Get explicit signup permission. Ask for the account name, email and a new Dashport password. register_account requires name, email and password (minimum 12 characters, maximum 72 bytes in the backend validation). Never reuse the customer backend’s password.
2. Call register_account. Retain the returned signup_token privately. Check email_sent. If true, tell the user the exact recipient email and ask them to relay the six-digit code. If false, do not claim a message was delivered.
3. Wait for the user’s code. Call verify_email with signup_token and the user-provided code. Never guess codes or request access to the mailbox.
4. Continue after verified: true. Call create_project with the same signup_token, a name and visibility (private or public). Ask before choosing public visibility.

{
  "name": "verify_email",
  "arguments": {
    "signup_token": "<private value returned by register_account>",
    "code": "<six digits supplied by the user>"
  }
}

Codes expire after 10 minutes, allow five failed attempts and can be used once. resend_verification_code uses the same signup token, waits at least 60 seconds, sends to the original email, invalidates the previous code and allows at most five deliveries during the one-hour setup window.

04. Build from the API, not from guesses.

1. Read get_context, get_capabilities, get_schema_reference and get_examples. Record the project/environment IDs returned by create_project.
2. Inspect the user’s actual API: origins, methods, paths, pagination, filters, response envelopes, IDs, relationships, authentication, permission flags and error shapes. Ask for missing facts.
3. Map connections, operations, resources, views, rules, actions, permissions, settings and navigation in the panel schema. Use field lookups for relations; define searchable or paged operations where necessary. Link widgets to the correct operations and response paths.
4. Use save_draft for a complete definition or the section-specific upsert_* tools. Include the latest expected_revision on writes. Signup-server project tools additionally require signup_token.
5. Run validate_panel, inspect preview_panel and diff_panel. Preview is a static schema summary, not a live rendering or a customer API test. Verify the real behavior in the target client.
6. On an appropriately authorized protected connection, freeze the intended draft with create_version. Only call publish_panel after an explicit user publication request, with the version and expected release revision.

A draft is not a mobile release. Publication must be explicit. Do not automatically add publishing permission or switch a private project to public to work around an authorization failure.

05. Current tool reference.

This list is generated from the server’s tool definitions. Full JSON includes argument schemas, required fields and annotations. The protected server filters tools according to the current grant and role.

Account setup — onboarding server

Panel lifecycle — protected server

The onboarding server also exposes the non-publishing tools below; they require a verified signup token and use the same project authorization checks.

06. Data boundaries & authorization.

• Direct customer requests: the panel client calls the customer API directly. Dashport is not the CRUD proxy. The platform still stores accounts, panel schemas, releases, grants and management metadata.
• Client credentials: configure supported login/token/OTP mappings. Keep per-user session credentials in the client’s protected session storage; never place real tokens, passwords, signing keys or signup tokens in a published schema.
• Server secrets: if an upstream requires a confidential machine credential, implement a suitable authenticated endpoint on the user’s backend. A mobile/web client cannot safely hold a server-only secret.
• Authoritative permissions: fields, modules and record actions can reflect API permissions. The customer backend must enforce every read/write and record-level access decision; hiding a button is not authorization.
• Trust: release manifests are signed and verified by the client’s trusted release keys. Panels use predefined components and a bounded declarative schema rather than arbitrary downloaded code. This is not an app-store approval guarantee.
• Network requirements: use valid HTTPS for production customer APIs. Web use additionally requires the correct CORS configuration. Private-network APIs must be reachable by the user’s device.

07. Schema vocabulary ≠ runtime support.

The contract includes the vocabulary below. It is not a promise that every installed app version implements every type. get_capabilities, client compatibility declarations and release resolution must be checked before choosing components. The platform’s generic capabilities response intentionally does not advertise a universal mobile renderer.

Fields in the contract

Views in the contract

Widgets in the contract

Contract limits

Panel JSON: 1,048,576 bytes maximum; nesting depth 32; rule depth 8; 16 action steps; 6 concurrent requests; default timeout 30000 ms. These safety limits also apply during the free introductory period.

08. Canonical schema & examples.

Panel JSON Schema is served from the backend’s canonical contract. Start with the closest example, then adapt it to the real API. Example origins and identities are illustrative, not live services or credentials.

• advanced-crm.panel.json
• blank-canvas.panel.json
• canvas.panel.json
• crm.panel.json
• provider-auth.panel.json
• public-catalog.panel.json
• review-demo.panel.json
• runtime-crm.panel.json
• showcase-crm.panel.json

Agent discovery: /.well-known/dashport.json. Short plain-text guide: /llms.txt. Expanded reference: /llms-full.txt. These are public reference documents; authentication remains required for account-specific operations.

09. Handle failures without bypasses.

• email_sent: false: retain signup_token, inform the user that delivery failed and retry with resend after the cooldown.
• invalid_verification_code, verification_attempts_exceeded, verification_code_expired: request a valid/new code, follow cooldowns and never guess.
• signup_session_expired or signup_session_revoked: stop using the setup credential. Existing registered users should authenticate through the protected MCP flow.
• invalid_arguments: inspect the tool schema and reported field names. An existing email should use the existing-account flow.
• draft_conflict: fetch the current draft, inspect changes, reconcile with the user and retry using the current revision. Do not overwrite blindly.
• Authorization failures: inspect context, role and scope; do not request broader permissions without the user’s intent.

For a panel the user can use on the phone, complete the draft review, obtain an authorized publication, then add/select that Dashport in the shared mobile client. Web manual editing is available in the console.