Developer Portal Overview

The current SeloraX "developer portal" is not a separate public REST service. It is the dashboard-facing app management surface exposed by the main backend and used by the SeloraX admin app.

These routes let merchants, internal teams, and app developers:

• create and manage app registry records
• submit apps for review and approve/reject listings
• install or uninstall apps on a store
• generate iframe embed parameters and refresh embedded session tokens
• manage merchant-owned webhook subscriptions and inspect delivery logs
• approve, decline, cancel, and complete app billing flows

Important Distinction

There are two API families in the platform:

1. Dashboard-facing app management APIs Used by the SeloraX admin dashboard with merchant/admin authentication. Examples:

   • /api/apps
   • /api/apps/installations
   • /api/apps/session
   • /api/apps/webhooks
   • /api/apps/billing

2. App-facing runtime APIs Used by installed apps with Bearer access tokens or client credentials. Examples:

   • /api/apps/v1/orders
   • /api/apps/v1/products
   • /api/apps/v1/billing
   • /api/apps/v1/webhooks

This section documents the dashboard-facing side. For runtime APIs, use the API Reference.

Authentication Model

These routes are protected by the dashboard auth stack, not by a separate developer access token.

Typical requirements are:

• authenticated admin session (auth)
• store-admin role checks (admin)
• store ownership validation (storeOwnership) where a store is involved
• feature permissions such as apps__manage_apps, apps__install_apps, or apps__view_webhooks

In practice, these routes are usually called from the SeloraX dashboard frontend rather than from third-party public clients.

Endpoint Groups

App registry and review

• GET /api/apps
• GET /api/apps/marketplace
• GET /api/apps/development
• GET /api/apps/review
• GET /api/apps/:app_id
• POST /api/apps
• PUT /api/apps/:app_id
• DELETE /api/apps/:app_id
• POST /api/apps/:app_id/submit-for-review
• POST /api/apps/:app_id/review
• POST /api/apps/:app_id/rotate-secret
• POST /api/apps/:app_id/generate-signing-key
• GET /api/apps/scopes

See Apps API.

Installations and embedded sessions

• POST /api/apps/installations/direct-install
• GET /api/apps/installations
• POST /api/apps/installations/:installation_id/uninstall
• GET /api/apps/session/embed-params
• POST /api/apps/session/session-token
• POST /api/apps/session/verify

These routes bridge the dashboard and embedded apps. The session routes are especially important for iframe loading and short-lived JWT refresh.

Merchant webhook management

• GET /api/apps/webhooks/subscriptions
• POST /api/apps/webhooks/subscriptions
• PUT /api/apps/webhooks/subscriptions/:id
• DELETE /api/apps/webhooks/subscriptions/:id
• PUT /api/apps/webhooks/subscriptions/:id/toggle
• PUT /api/apps/webhooks/subscriptions/batch
• DELETE /api/apps/webhooks/subscriptions/batch
• PUT /api/apps/webhooks/subscriptions/batch/toggle
• GET /api/apps/webhooks/deliveries
• POST /api/apps/webhooks/deliveries/:delivery_id/retry

See Webhooks API.

Merchant-facing app billing

• GET /api/apps/billing/charges/:id
• POST /api/apps/billing/charges/:id/approve
• POST /api/apps/billing/charges/:id/decline
• POST /api/apps/billing/charges/:id/cancel
• GET /api/apps/billing/callback
• GET /api/apps/billing/history

These are the approval and completion routes used after an app creates charges through the runtime Billing API.

When To Use Which Docs

• If you are building an app backend that calls SeloraX with app credentials, start with API Overview.
• If you are building an embedded app iframe, read Session Tokens and Session Token Flow.
• If you are working on dashboard-side app lifecycle screens, use this Developer Portal section.

Current State

This section reflects the app platform that exists in the main SeloraX backend today. Older references to a separate portal.selorax.io/api/v1 surface are obsolete for the current implementation.