sallaapp

@sallaapp source repo

27 skills
0 followers
5 hours ago last updated

▌
Salla Docs · sallaapp bundle
Find the right Salla documentation or API schema fast. Use when you need a doc link, an endpoint's exact request/response shape, an event payload schema, or you're unsure where something is documented. Routes each topic to its scoped public docs entry point on docs.salla.dev. Never start from the full docs index (llms.txt) — it spans the Merchant API, storefront themes, and more; app development is only a small slice of it.

0
installs
▌
Salla API Core · sallaapp bundle
Foundation reference for the Salla Admin (Merchant) API — base URL, Bearer-token auth, request headers, merchant identity, common resource endpoints, pagination, rate-limit tiers/headers, HTTP status codes with slugs, structured error shapes, and the App Settings read-modify-write pattern. Use whenever writing, reviewing, or debugging any Salla Admin API call — auth setup, pagination, error handling, app-settings read/write, or rate limits. Every other Salla skill builds on this; merchant token handling → salla-app-auth.

0
installs
▌
Salla App Auth · sallaapp bundle
Salla OAuth 2.0 and merchant token management — the Salla delta on standard OAuth: Easy Mode (tokens via the app.store.authorize webhook, no callback — published apps) vs Custom Mode (authorization-code, dev/testing only), the offline_access scope, single-use refresh tokens needing a per-merchant refresh lock, and the User Info endpoint. Use before writing any Salla token-handling code. Lifecycle events → salla-app-lifecycle; webhook verification → salla-webhooks; API usage → salla-api-core.

0
installs
▌
Salla Snippets · sallaapp bundle
Use when behavior must run in the shopper's browser on the Salla storefront — JS snippets injected via the salla_snippets tool, reacting to storefront e-commerce events (cart, product view, checkout, search). Rule: storefront/browser behavior → snippet (Device Mode); server-side handling of the same events → App Function (salla-app-functions, Cloud Mode). Snippets are pure-JS files served from the CDN, placed before `</body>`; covers create/update/delete, the `salla.config.get("app.*")` settings bridge, and the storefront event catalogue.

0
installs
▌
Salla Webhooks · sallaapp bundle
Salla webhooks end to end — registering/subscribing, choosing a security strategy (signature = HMAC of the raw body; token = plain equality of the Authorization header; or none) and verifying each correctly, the payload envelope, idempotency, fast 200, conditional rules, and versions (v1/v2). Use when building a webhook server (Node/Express `@salla.sa/webhooks-actions` or Laravel/PHP / Salla CLI), subscribing events, or debugging delivery. Prefer an App Function (salla-app-functions) when a trigger exists. Lifecycle → salla-app-lifecycle; tokens → salla-app-auth.

0
installs
▌
Salla App Expert · sallaapp
FIRST stop for Salla app development — load before generic brainstorming or planning. Use when building, configuring, or debugging a Salla app, when the task is broad ("build a Salla app", "add X to my app"), or when unsure which Salla skill applies. Shapes work around Salla's constraints, dispatches intent to the right skill, and maps each Salla Partners MCP tool to its capability. For a specific subsystem (OAuth, webhooks, settings, billing, publishing…), go straight to its skill.

0
installs
▌
Salla App Billing · sallaapp bundle
Salla app monetization: plans and addons live in the publication's pricing section (no separate pricing endpoint), billed by Salla. Use when pricing the app, tracking plan/addon state, or gating features by entitlement. Track state from app.subscription.* / app.trial.* events (one family — item_type splits plan vs addon), reconcile via salla_apps action=subscriptions, meter usage against the balance. Signatures → salla-webhooks; tokens → salla-app-auth; wiring → salla-app-lifecycle; in-app purchase UI → salla-addon-purchase / salla-addon-purchase-embedded.

0
installs
▌
Salla App Builder · sallaapp bundle
Use when creating a new Salla app or driving any create-to-publish step via the Salla Partners MCP — "create a new Salla app", configure scopes/webhooks, or publish. The spine; it hands off mechanics to the owning skill: snippets → salla-snippets, embedded pages → salla-embedded-app, App Functions → salla-app-functions, settings → salla-app-settings, OAuth/tokens → salla-app-auth, webhooks → salla-webhooks, billing → salla-app-billing, publish checks → salla-publication-consistency. Type deltas: salla-shipping-app, salla-communication-app.

0
installs
▌
Salla Embedded UI · sallaapp bundle
Owns native look-and-feel for a Salla app's EMBEDDED (dashboard) UI — the Partner-dashboard iframe on the Embedded SDK design system. Use WHENEVER an embedded/dashboard page draws visible UI (settings, analytics, addon flows). Its five binding gates must all pass — none skippable — and the final gate is a live demo-store screenshot. Not done until verified. Storefront UI → salla-storefront-ui; SDK/auth wiring → salla-embedded-app.

0
installs
▌
Salla App Settings · sallaapp bundle
Per-merchant settings for a Salla app. Use when designing a settings schema, registering the form, or reading/writing merchant config. Covers the salla_settings form + optional Validation URL, supported-features declaration (publish-blocker for communication apps), seeding defaults on install, value read/write (POST is a full replace — send ALL keys), reacting to app.settings.updated (activates the app AND is the storage source of truth), and context.settings in App Functions. Admin API → salla-api-core; lifecycle → salla-app-lifecycle.

0
installs
▌
Salla Embedded App · sallaapp bundle
Use when building an iframe page inside the Salla Merchant Dashboard (an embedded app). Register it via salla_embedded_pages, install @salla.sa/embedded-sdk, await embedded.init() (postMessage bridge → layout: theme/locale/dir), then authenticate Trust-but-Verify: FE embedded.auth.getToken() sends a short-lived token to YOUR backend, which verifies it via POST /exchange-authority/v1/introspect (header S-Source = your App ID) and mints its own session; call embedded.ready() only after that. Use native Page/Nav/UI modules (No-Chrome rule), sync theme/RTL. Selling addons in-app → salla-addon-purchase-embedded; publish flow → salla-app-builder.

0
installs
▌
Salla Live Testing · sallaapp
Validate a Salla app on a real demo store before calling it done. Use when verifying an app end to end before publish. Install via salla_apps action=demo_stores, then verify the settings form actually SAVES, the embedded dashboard authenticates, the storefront snippet renders, and webhooks / App Functions fire from real Salla events. MCP/config success and passing endpoint tests are NOT proof the integration works — this is the live gate. Build flow → salla-app-builder; storefront UI → salla-storefront-ui; embedded UI → salla-embedded-ui.

0
installs
▌
Salla Shipping App · sallaapp bundle
Build a Salla shipping app in two models — Shipping Management (one carrier: the modern Salla AWB model, App Functions inside Salla Partners, no backend) or Order Fulfilment (auto-dispatch across carriers). Create it, configure zones via salla_shipping, implement the sync App Functions shipment.creating (returns a Shipment with AWB + PDF label) and shipment.cancelling (returns Resp). Use when building for any carrier, AWB, label, tracking, COD, or return task. App Functions → salla-app-functions; OAuth → salla-app-auth; webhooks, publish → salla-webhooks, salla-app-builder.

0
installs
▌
Salla App Functions · sallaapp
Router for building Salla App Functions — serverless TS/JS handlers Salla runs in a sandboxed V8 on store events (e.g. `order.created`, `shipment.creating`). Start here for any App Function task, then follow the step skills: design the trigger, write the handler, validate, test, release. Prefer App Functions over webhooks; act with `salla_functions`. Builds on salla-api-core and salla-webhooks.

0
installs
▌
Salla App Lifecycle · sallaapp bundle
Salla app lifecycle webhook events — what Salla fires as a merchant installs, updates, uninstalls, trials, and subscribes. Use when handling `app.installed`, `app.store.authorize`, `app.updated`, `app.uninstalled`, `app.trial.*`, or `app.subscription.*`; provisioning on install; cleaning up on uninstall; or building the merchant state machine (installed → trial → active → expired → uninstalled). Builds on salla-webhooks (signature, idempotency, fast 200) and salla-app-auth (token storage). Plan/trial state and entitlements → salla-app-billing.

0
installs
▌
Salla Storefront UI · sallaapp
Make a Salla app's STOREFRONT (the store) UI native — shopper-facing pages on the Twilight theme. Build from native `<salla-*>` web components driven by the Storefront JS SDK, inherit Twilight CSS tokens, use Salla Icons (`sicon-*`), match the page's spacing, write Arabic-first/RTL, and verify with a LIVE screenshot on an installed demo store (`url`). Use when a snippet draws visible UI. Injection recipe → salla-snippets. Embedded/dashboard UI → salla-embedded-ui.

0
installs
▌
Salla Addon Purchase · sallaapp
The addon billing lifecycle for a Salla app — defining an addon, activating on app.subscription.started (item_type "addon", matched by item_slug), persisting the entitlement, and handling renewal/cancellation/expiry. Use when wiring what happens AFTER a merchant buys an addon, tracking addon subscriptions, or gating features by addon. The in-iframe purchase UX is part of the embedded flow → salla-addon-purchase-embedded. Plan/pricing/entitlement primitives → salla-app-billing; webhook hygiene → salla-webhooks.

0
installs
▌
Salla App UI Builder · sallaapp bundle
The Salla app's App Store listing page (the page merchants see before installing). Use when customizing that listing page. Build it via the `app_page_builder` MCP tool as an ordered list of blocks; editing a block's elements writes shared listing content (name, description, logo, screenshots, benefits) into the app's draft publication. Prerequisite: call `app_publish action=open` first to create the draft — the builder is disabled until then. Upload media with `salla_upload`. Draft/publish flow and `short_description` → salla-publication-consistency. Schemas → salla-docs.

0
installs
▌
Salla Communication App · sallaapp bundle
Build a Salla Communication App that delivers SMS, WhatsApp, or email on the merchant's behalf. Use when building channel apps, OTP/notification delivery, or the communication.*.send events. Salla deltas: no sub_category_id, zero default webhooks, channels MUST be declared via supported-features before publish (else 403), and each send event is an App Function trigger — prefer App Functions. App creation → salla-app-builder; credentials → salla-app-settings; handler code → salla-app-functions; token/OAuth → salla-app-auth.

0
installs
▌
Salla App Functions Test · sallaapp
Run a saved Salla App Function on a demo store with `salla_functions action=preview` (app_id, trigger, store_id, and the trigger's form fields as REAL ids). Use after save to verify behavior before publishing; poll `salla_functions action=deploy_status` while it is still deploying. Routed from salla-app-functions; uses salla-api-core to fetch real ids.

0
installs
▌
Salla Snippets Migration · sallaapp bundle
Use when converting a legacy Salla app snippet — raw HTML/Twig with `<script>`/`<style>`/ markup, or `{{namespace.key}}` tokens — into the pure-JS format the `salla_snippets` CDN pipeline requires. Trigger on any `{{...}}` token, HTML markup in snippet content, or a PreToolUse nudge from `salla_snippets`. Owns parameter conversion only. Hand-offs → salla-snippets (owns the actual create/update call, JS validation, and the forbidden-parameter check — this skill's rules and that gate must never disagree).

0
installs
▌
Salla App Functions Design · sallaapp bundle
Step 1–2 of building a Salla App Function: pick the trigger, confirm its exact `payload.data` shape, and choose a synchronous action (runs before the operation, can block/modify, 5 s total) vs an asynchronous event (runs after, fire-and-forget, 30 s). Use before writing the handler. Routed from salla-app-functions; next is salla-app-functions-handler.

0
installs
▌
Salla App Functions Handler · sallaapp
Step 3 of building a Salla App Function: write the handler body from the trigger's `template`. Use when coding the logic — reading typed `context` (payload/merchant/settings), returning the response contract via the `Resp` (or entity `Shipment`) builder, staying inside the V8-isolate sandbox (web-standard APIs, `fetch` for HTTP), and bounding each `fetch` to the sync/async timeout. Routed from salla-app-functions; validate next with salla-app-functions-validate. Token-handling → salla-app-auth; API details → salla-api-core.

0
installs
▌
Salla App Functions Release · sallaapp
Save & publish a Salla App Function — `salla_functions action=save` deploys to demo stores (poll `action=deploy_status`), then the app is published. Use after validating the handler, when you're ready to deploy and ship a function to production. Routed from salla-app-functions; test first → salla-app-functions-test; app publication → salla-app-builder / salla-publication-consistency; OAuth/tokens → salla-app-auth; webhook verification → salla-webhooks.

0
installs
▌
Salla App Functions Validate · sallaapp
REQUIRED before saving a Salla App Function: keep the template's wrapper exactly — its first AND last line — with all code inside the wrapper (no hoisted const/helper), and type-check the handler with the TypeScript compiler against the trigger's `types` (.d.ts URLs) at the editor's bar — non-strict, ignoring unused (TS6133) — plus validate any documented Admin API call against its OpenAPI schema (salla-api-core loop). `salla_functions action=save` validates ONLY those wrapper lines. Routed from salla-app-functions; release with salla-app-functions-release.

0
installs
▌
Salla Addon Purchase Embedded · sallaapp
The in-app addon purchase UX inside an embedded Salla app — list the app's add-ons, open a native checkout, and hear the payment result via the embedded SDK Checkout module (`embedded.checkout.getAddons` / `.create` / `.onResult`). Salla owns billing; never collect payment in the iframe. Use when building the buy/upsell UI in an embedded page or wiring the checkout handoff. Part of the embedded flow → salla-embedded-app. Activation + entitlement lifecycle after purchase → salla-addon-purchase.

0
installs
▌
Salla Publication Consistency · sallaapp bundle
Use when a PUBLIC Salla app is going to review (App Store listing): the master skill for stepwise publication via app_publish. It reads the current draft, routes each step to its owner, and HARD-GATES sending to admin review behind a clean validate plus the partner's explicit confirmation. Private apps publish from the Portal — see salla-app-builder. Hand-offs: listing/images → salla-app-ui-builder; pricing + billing cycle → salla-app-billing; scopes → salla-app-auth; webhooks → salla-webhooks; settings → salla-app-settings.

0
installs

27 published skills