Guía de la API del panel SMM: creación de un flujo de trabajo de revendedor verificable

La API SMM Africa es un punto final único basado en acciones para flujos de trabajo de catálogo, saldo, pedido, estado, recarga y cancelación. Acepta JSON, campos codificados en URL y datos de formularios de varias partes de solo campos, por lo que los paneles de revendedores comunes se pueden integrar sin un adaptador.

La API no elimina la variabilidad del proveedor ni las responsabilidades del revendedor. Una integración sólida mantiene una instantánea del servicio actual, asigna a cada cliente el ID de pedido SMM Africa, conserva el objetivo y la cantidad enviados y presenta el estado y la elegibilidad para reembolso o recarga con precisión.

Punto final y autenticación

Enviar una solicitud POST HTTPS a https://smm.africa/api/v3 con JSON, application/x-www-form-urlencodedo solo campo multipart/form-data. Autenticar con Authorization: Bearer YOUR_API_KEY o el estándar key campo. Se recomiendan campos codificados en URL para paneles de revendedores comunes.

curl -X POST https://smm.africa/api/v3 -H "Content-Type: application/x-www-form-urlencoded" --data-urlencode "key=YOUR_API_KEY" --data-urlencode "action=balance"

Conserve la clave en el servidor. No lo envíe en JavaScript del navegador, un paquete móvil, un repositorio público, registros visibles para el cliente, eventos de análisis o capturas de pantalla. Aléjelo de los controles de seguridad de la cuenta si pudo haber estado expuesto.

Las seis acciones documentadas

• servicios: devuelve el catálogo de servicios actual.
• saldo: devuelve el saldo y la moneda de la billetera compartida.
• añadir: envía un pedido para un ID de servicio, objetivo y cantidad actuales.
• estado: devuelve campos operativos para un ID de pedido SMM Africa.
• recarga: solicita una revisión de recarga para un pedido elegible.
• cancelar: solicita la cancelación de un pedido elegible.

Las seis acciones utilizan el mismo punto final. El action valor decide la forma de la solicitud y la respuesta.

Obtener servicios antes de exponer un catálogo

La services respuesta documenta un ID de servicio, nombre, tipo, categoría, tarifa, mínimo, máximo, indicador de recarga y indicador de cancelación. El contrato v3 utiliza USD independientemente de la moneda de visualización del sitio web. Lea cada tipo de servicio: las tarifas de cantidad estándar se utilizan por cada 1000, mientras que los paquetes tienen diferentes reglas de facturación. Los ID de servicio, precios, límites, nombres e indicadores pueden cambiar, así que no los codifique como datos permanentes del producto.

Un revendedor puede almacenar en caché la respuesta para facilitar su uso, pero debe registrar cuándo se obtuvo y actualizarla antes de aceptar un pedido. Si el catálogo de cara al cliente cambia un nombre o precio, conserve el ID de servicio SMM Africa original y los detalles que se muestran cuando se realizó el pedido.

Realizar un pedido con la acción de agregar

Para un servicio predeterminado, el add acción requerida service, linky quantity. Otros tipos de servicios utilizan sus campos documentados. Opcional runs y interval se aplican solo a servicios de alimentación por goteo compatibles. Valide el objetivo con la nota de servicio en vivo y mantenga la cantidad entre el mínimo y el máximo actuales.

{ "action": "add", "service": 1234, "link": "https://instagram.com/your-profile", "quantity": 500
}

Una respuesta exitosa devuelve un order valor. Almacene esa identificación inmediatamente con la referencia del cliente, la instantánea del servicio, el objetivo, la cantidad enviada, el cargo esperado y la marca de tiempo. El revendedor es propietario de este mapeo; la API no puede inferir qué cliente final o factura pertenece al pedido.

Representar el estado con precisión

La status acepta el ID de pedido SMM Africa. La respuesta documentada puede incluir cargo, recuento inicial, estado del pedido, restos y moneda. Las posibles etiquetas de estado incluyen Pendiente, En curso, Procesando, Parcial, Completado y Cancelado.

Utilice estos campos para mostrar el progreso del pedido en un portal de cliente. Mantenga los informes de campaña separados y utilice los análisis de la plataforma social para determinar el alcance, la participación y la respuesta de la audiencia.

La recarga y cancelación son solicitudes, no promesas

La refill y cancel ambas acciones utilizan un ID de pedido. Un indicador de servicio actual puede indicar si una acción está expuesta, pero la elegibilidad final aún depende del servicio, el estado del pedido, el momento, la respuesta del proveedor y la política publicada.

No prometa a un cliente que cada gota será recargada o que cada pedido enviado podrá cancelarse. Conserve la lista original, las marcas de tiempo del pedido y la respuesta para que el soporte tenga la evidencia necesaria para la revisión.

Manejo de errores y sondeo

• 400: inspeccione la solicitud y los campos obligatorios.
• Error de autenticación 400: deténgase y revise la clave; no vuelva a intentar credenciales no válidas continuamente.
• 429: respetar el Retry-After encabezado y retroceder.
• 500: registre un registro de correlación redactado y vuelva a intentarlo de forma conservadora en lugar de crear pedidos duplicados.

Nunca registre el token de portador completo. Si se produce un error de red después del envío add, verifique si el pedido se creó antes de enviar la misma solicitud del cliente nuevamente.

Una secuencia de integración más segura

1. Leer el referencia de API humana y Documento OpenAPI.
2. Probar la autenticación con balance e inspeccionar el actual services respuesta.
3. Realice un pequeño pedido manual para el ID de servicio exacto y el tipo de objetivo que planea exponer.
4. Observar el estado del pedido, la variabilidad del tiempo y cualquier comportamiento de recarga o cancelación.
5. Construya el cliente del lado del servidor, la instantánea del servicio, la asignación de pedidos, los registros redactados y el manejo de límites de velocidad.
6. Explique la entrega, la plataforma, la retención, la opción de soporte y los límites de los resultados en sus propios términos de cliente.

Conclusión

Una API de panel SMM puede hacer que un flujo de trabajo probado sea más fácil de operar. Utilice la documentación actual, conserve el ID del servicio y el ID del pedido, asegure la clave y presente el estado del pedido con precisión a los clientes.

Un intercambio de pedidos estándar completo

Los valores a continuación son marcadores de posición, no ID de servicios en vivo, credenciales, precios o resultados de pedidos. Busque los servicios primero y elija un servicio predeterminado compatible. Todos los montos de la versión 3 utilizan USD; La moneda de visualización del sitio web no cambia ese contrato.

POST https://smm.africa/api/v3
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
Idempotency-Key: example-client-order-001 { "action": "add", "service": 1234, "link": "https://instagram.com/your-profile", "quantity": 500
}

Respuesta ilustrativa exitosa:

{ "order": "example-order-id", "charged": 1.25 }

Guarde el ID del pedido devuelto y luego solicite su estado:

POST https://smm.africa/api/v3
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json { "action": "status", "order": "example-order-id" }

Inspeccionar estado, restos, carga, actualizado_at y frescura. Un estado obsoleto es información almacenada en caché, no una verificación nueva del proveedor; una marca de tiempo de actualización faltante no debe presentarse como verificación reciente. Utilice el Referencia de OpenAPI para formas de respuesta completas y casos de error.

Manejar un tiempo de espera sin cargo duplicado

Asigne una clave de idempotencia opaca a cada orden lógico y mantenga su solicitud exacta. Cuando se agote el tiempo de espera de la misma orden, reutilice esa clave y las mismas entradas dentro del período de reproducción documentado. No cree una nueva clave sólo para evitar un conflicto. Las respuestas de agregar actuales se pueden reproducir durante 24 horas; después de la expiración, concilie el pedido original antes de volver a intentarlo. Los clientes estándar pueden utilizar el campo de formulario idempotency_key en lugar de un encabezado.

Una respuesta de API o un registro de pedido local confirma el estado del flujo de trabajo, no la retención, la calidad de la audiencia o los resultados comerciales. Nunca incluyas claves en el código de interfaz, capturas de pantalla o análisis.

Diferencias de error y tipo de servicio

Un pedido predeterminado utiliza enlace y cantidad. Un paquete utiliza un enlace sin cantidad. Los comentarios personalizados derivan la cantidad de las líneas de comentarios. Obtenga texto del catálogo y siga la referencia API actual en lugar de enviar todos los campos para cada servicio.

Los errores de autenticación y validación pueden devolver HTTP 400 con un mensaje de error; los tipos de contenido no admitidos usan 415, cuentas suspendidas 423 y límites de velocidad 429 con Retry-After. No vuelva a intentar una solicitud rechazada sin cambios. Retroceda después de los límites de velocidad y concilie los envíos inciertos antes de volver a intentar errores de servidor o de red.