System Routes

Depending on the type of integration, Boltic Gateway can automatically generate and manage system routes for you.

warning

System routes are automatically generated and managed by Boltic Gateway. You cannot modify or delete (in some cases) these routes.

Boltic Tables

When you configure a route with the Boltic Table integration type, a standardized set of system-generated API endpoints is automatically created to enable CRUD operations and metadata access for that table.

These system routes are:

• Auto-generated upon integration.
• Immutable – they cannot be edited, overridden, or deleted manually.
• Scoped to the selected path.
• Environment-aware – available separately in Test and Production environments.

---

List of Auto-Generated Routes

Method	Route	Description
POST	/{your_path}/records	Fetch all records from the table with filters, pagination, and sorting.
POST	/{your_path}/schema	Retrieve the full schema definition of the table (columns, types, constraints).
POST	/{your_path}/record	Create a new record in the table using a JSON body.
GET	/{your_path}/record/:id	Fetch a single record by its unique identifier.
PUT	/{your_path}/record/:id	Update an existing record using its ID and request body.
DELETE	/{your_path}/record/:id	Delete a record permanently from the table by ID.

Fynd Platform Extensions

When a route is configured with the Fynd Platform Extension integration type, a standardized set of system-managed endpoints is automatically generated. These routes handle the full lifecycle of extension installation, authentication, and uninstallation between your service and the Fynd Platform.

These routes are:

• Predefined and Immutable – Cannot be edited, deleted, or overridden.
• Available on every extension-enabled gateway.
• Mapped automatically to the logic you configure in your extension backend.
• Triggered by the Fynd Platform as part of the OAuth + installation lifecycle.

List of Auto-Generated Routes

Method	Route	Description
GET	/fp/install	Initiates the installation flow. Called by the Fynd Platform when a merchant starts installing the extension.
GET	/fp/auth	Handles the OAuth authentication callback and finalizes app authorization.
POST	/fp/uninstall	Called when the extension is uninstalled by a merchant. Used to clean up resources or tokens.

System Behavior & Requirements

• Installation Flow (/fp/install)

  • The Fynd Platform redirects to this route when a merchant begins the installation.
  • This endpoint should redirect the user to an authorization screen or start the OAuth handshake.

• Authentication Callback (/fp/auth)

  • Receives the auth code, validates it, and exchanges it for access tokens.
  • You are expected to persist these credentials securely for subsequent API calls to Fynd Platform.

• Uninstallation Handler (/fp/uninstall)

  • Triggered automatically when a merchant removes your extension.

  • You should use this route to:

    • Revoke tokens
    • Delete tenant-specific data
    • Clean up database entries or active sessions

Security & Validation

• All /fp/* routes are called by Fynd Platform servers.
• Authentication is handled automatically Boltic Gateway allowing users to focus on their core business logic.
• No manual validation or authorization checks are required.

Extension Lifecycle Overview

1. Install Initiated → Merchant clicks install → Fynd redirects to /fp/install
2. Auth Completed → OAuth completed → Fynd calls /fp/auth with auth code
3. Merchant Uses Extension → Backend uses saved token to serve business logic
4. Uninstall Triggered → Merchant uninstalls → Fynd calls /fp/uninstall

System Behavior & Features

• Strict Validation All system routes enforce automatic request validation based on the schema defined in the Boltic Table.

• Audit & Metadata Each system route logs request metadata such as request ID, environment, auth method, and timestamps—available in the Logs tab.

• Environment-Specific Data Test and Production environments maintain isolated datasets, enabling safe testing without affecting live records.