Platform overview: roles and panels

Purpose#

Delivery Syria is one platform with several kinds of users, each working in a different place with different menus. This page explains who they are, where they work and how their work connects, so you know which guide to read next.

Who is who#

How the roles connect#

1. The super admin creates a delivery company. This also creates the company's subdomain and its first admin account, whose permissions come from the modules of the company's plan. A company can also register itself on the company sign-up page of the main domain, which confirms the account with a one-time code (OTP).
2. The company builds its team. Company staff add couriers and merchants. Merchants can also register themselves on the company's site, on its merchant sign-up page.
3. Independent merchants join directly. They register at /join on the main domain and are sent to choose and pay for a merchant plan. Such an account is a VIRTUAL_MERCHANT that owns an internal delivery company, so its menu has a My delivery company section with its own couriers and dispatch.
4. A parcel travels through the roles. The merchant creates it, the company dispatches it to a courier, the courier updates its status from the app, and the recipient follows it on the public tracking page, which the QR code on the waybill printed from the merchant panel opens.
5. The super admin manages warehouses. The Warehouse service is off until the super admin turns it on in the Warehouse service menu. The super admin creates warehouses, reserves pallets for merchants and creates supervisor accounts. An independent merchant sees the Warehouses menu only when the service is enabled for that merchant (which can also depend on the merchant plan) or when the merchant holds an active pallet reservation. Supervisors record goods in and release parcels.

Signing in and finding your panel#

1. Open the login page

   Super admins sign in on the main domain only. Everyone else can sign in there too: after a correct password they are sent to their own company's domain, normally with a one-time link that is valid for 2 minutes.

2. Check where you land

   Every web role opens /dashboard and is routed to its own page. A super admin sees the platform dashboard. An independent merchant sees the merchant home page, or the plans page if there is no active merchant plan; a merchant that belongs to a delivery company is checked against the company's subscription instead of a merchant plan. A warehouse supervisor goes to /warehouse-panel. Company staff whose company has no active subscription are sent to the company plans page. Otherwise a company admin or in-charge sees the company dashboard, and other company staff, such as hub accounts, see the classic company dashboard.

3. Use the menu you are given

   Most company menu items appear only if the account has the matching permission, and a direct link to a protected page redirects to the home page. The merchant menu does not use permissions, but a merchant who belongs to a delivery company does not see the account statement, the plan page link or the Integration section (store integrations, API and webhooks).

Common mistakes#

• Signing in as super admin on a company address. The sign-in is rejected. With a correct password the message says the super admin signs in from the main domain only.
• Looking for company menus on the main domain. The classic company pages for parcels, couriers and salary are registered only on company domains. The main domain has a reduced set, such as merchants, hubs, users, plans and companies.
• Expecting a courier web panel. Couriers have no web panel: they work in a mobile client that talks to the courier API (/api/v10), and the app itself is a separate client that is not part of the platform's own code. On the web, couriers are managed by company staff and by merchants that own an internal delivery company (My delivery company).
• Seeing the plans page instead of the dashboard. An independent merchant with no active merchant plan is redirected there. Company staff of a company without an active subscription are sent to the company plans page instead.
• A suspended account. Signing in directly on the company domain with a correct password shows that the account is suspended. Signing in on the main domain with a suspended account redirects first and then fails with a message that the login link has expired. API requests with the account's token return HTTP 401 on routes protected by the account-type check (for example the courier endpoints), and a suspended courier gets HTTP 403 at courier login.

Limits and permissions#

• A company needs an active subscription, except platform-owned companies and companies owned by a merchant.
• For independent merchants, Import from Excel and Store integrations depend on the import and stores feature flags of the merchant plan (the flags apply when the platform has active merchant plans). A merchant that belongs to a delivery company is not subject to merchant-plan flags, so it can use Import from Excel. Store integrations (like the merchant API and webhooks) are for independent merchants only: a merchant that belongs to a delivery company does not see them in the menu, and if it opens such a page by direct link it is redirected to the dashboard with a warning.
• Account type rules are enforced on the server. Super admin always passes. Any other account must match the route, otherwise the API returns HTTP 403 listing the allowed roles.
• The warehouse panel is only for warehouse supervisor accounts linked to a warehouse. Others get a 403 page.
• Most courier API requests (sign-in, parcels, delivery, dashboard) must also send the apiKey header, otherwise the API answers Invalid Api Key (HTTP 400). The live-tracking calls (online/offline switch, location, tracking settings) and the parcel location update do not need that header; they need only the courier's access token.
• The public tracking page needs no sign-in, is rate-limited to 60 requests per minute, hides part of the recipient's name and phone, and asks search engines not to index it.