🤖 Интеграция с Claude Code / Codex Опционально

Перепродаёте SMMDude на собственном сайте? Это один из необязательных способов интеграции — если вы предпочитаете настроить всё сами, полное описание есть в разделе «Действия» ниже. Если вы хотите, чтобы это сделал ИИ-агент для написания кода, скопируйте промпт ниже в Claude Code, Codex или любого другого ИИ-агента, работающего в репозитории вашего проекта. Промпт самодостаточен (агенту не нужен доступ в интернет, чтобы его использовать), указывает агенту не менять существующий дизайн и хранить ваш API-ключ только на сервере.

You are integrating the SMMDude reseller API into this existing project. Follow these rules carefully.

GOAL
Add the ability for this project's users to browse SMMDude's service catalog, place orders, and check order status — using SMMDude as the backend fulfillment provider — while preserving 100% of this project's existing design, styling, framework, and UI conventions. Do not introduce a new design system, new CSS framework, new component library, or restyle any existing page. Match the existing look and feel exactly. If this project has no relevant UI yet, build the minimum necessary and mimic its existing visual patterns as closely as possible (same CSS classes/components/spacing conventions it already uses).

BEFORE YOU START
1. Explore the existing codebase: identify the language/framework (Node/Express, Django, Flask, Laravel, Rails, etc.), the templating or frontend approach, the existing auth/session system, and the database.
2. Identify where a new backend module/route/controller should live given this project's existing conventions (naming, folder structure, error handling style, code style).
3. If anything is ambiguous — e.g. where to track user wallet balance, whether to build a full UI or just a backend layer, how much markup/pricing to apply — ask the user before proceeding rather than guessing.

SECURITY — NON-NEGOTIABLE
- The SMMDude API key must NEVER be exposed to the browser/client. Store it server-side only (an environment variable, e.g. SMMDUDE_API_KEY), and make all SMMDude API calls from your backend only.
- Build a small backend service/module that calls SMMDude on behalf of your users; your frontend must call YOUR OWN backend, never smmdude.com directly.
- Validate and sanitize all user input (link, quantity, service id) server-side before forwarding it to SMMDude, and re-check quantity against that service's min/max.
- Never let a user pass their own arbitrary "key" or "action" through to the SMMDude API — your backend should hardcode the action per endpoint and always use the server-side API key.

SMMDUDE API REFERENCE (self-contained — you do not need internet access to complete this task)

Base endpoint: POST https://smmdude.com/api/v2
Body format: application/x-www-form-urlencoded OR application/json (either works)
Every request must include:
  key    - the SMMDude API key (server-side secret, never client-side)
  action - one of: balance, services, add, status, multi-status, refill, cancel

1) action=balance
   Params: key, action
   Response: { "balance": "42.50", "currency": "USD" }

2) action=services
   Params: key, action
   Response: a JSON array, each item shaped like:
     { "service": 12, "name": "Telegram Members [Non Drop 30 days]", "type": "Default",
       "category": "Telegram Members", "rate": "0.4725", "min": 10, "max": 100000,
       "dripfeed": true, "refill": false, "cancel": true }
   "rate" is the price per 1000 units, in USD, already at the reseller's own pricing.

3) action=add
   Params: key, action, service (the service id from services action), link, quantity
   Response on success: { "order": 1045 }  <- this is YOUR order id, store it against your own user/order record
   On failure: non-2xx HTTP status with { "error": "human readable message" } (e.g. insufficient balance, bad quantity, invalid service). Surface this error to the user; do not deduct any local balance you track unless this call succeeds.

4) action=status
   Params: key, action, order (the order id returned by add action)
   Response: { "charge": "4.7250", "start_count": 1204, "status": "In progress", "remains": 3200, "currency": "USD" }

5) action=multi-status
   Params: key, action, orders (comma-separated order ids)
   Response: an object keyed by order id, each value shaped like the status response, e.g.
     { "1045": { "charge": "4.7250", "start_count": 1204, "status": "Completed", "remains": 0, "currency": "USD" },
       "1046": { "error": "Order not found" } }

6) action=refill
   Params: key, action, order
   Only works if that specific service's "refill" flag was true in the services response. Otherwise expect an error.

7) action=cancel
   Params: key, action, order
   Only works if that specific service's "cancel" flag was true in the services response. Otherwise expect an error.

Full human-readable docs (kept up to date, in case you do have web access and want to double-check anything): https://smmdude.com/api-docs

WHAT TO BUILD
1. A server-side SMMDude client module that wraps the 7 actions above, reading the API key from an environment variable. Keep it small and dependency-free (a single POST request each time is enough — no SDK needed).
2. A way to sync or cache SMMDude's services catalog into this project's own data layer (on a schedule, or on demand with a short cache) so pricing/browsing doesn't hit the SMMDude API on every page view.
3. An order-placement flow: a backend endpoint that this project's existing (or minimal new) UI can call, following this project's existing auth/session pattern, which validates the request, calls SMMDude's add action, and records the resulting order id against this project's own user/order records — mirroring however this project already tracks purchases, credits, or orders, if it does.
4. An order-status flow: a way for users to see the current status of their orders, by calling status or multi-status on demand or on a schedule.
5. Wire steps 3 and 4 into the EXISTING UI wherever this project already has a concept of "orders," "purchases," or "services" — reuse existing pages/components/navigation rather than creating new, differently styled ones.

WHEN YOU ARE DONE
Summarize exactly what you built and where, state clearly which environment variable(s) need to be set and how, and list any manual step the user still needs to take (e.g. adding the env var to their host, running a migration, obtaining their SMMDude API key from https://smmdude.com/dashboard/settings).