API de TaiVPS v19: cómo listar VPS con cURL

En pocas palabras: Para listar los tipos de VPS de tu cuenta en la API v19 de TaiVPS, enviás un POST con cURL a https://taivps.net/api/v19 con auth_token y action=loaivps como form data. Es una consulta de solo lectura y devuelve pares type y name, como vps-gold, vps-platinum y vps-vip.

La API de TaiVPS v19 tiene una petición de solo lectura, action=loaivps, que lista los tipos de servicio VPS de tu cuenta. Se llama con un POST de cURL a https://taivps.net/api/v19, con auth_token y action como form data, y no compra ni modifica nada.

La API v19 de TaiVPS es la interfaz HTTP del proveedor TaiVPS para consultar y operar servicios VPS desde código, por ejemplo en un selector de planes o en la integración de un revendedor. Según la guía publicada en dev.to el 9 de octubre de 2026, el endpoint recibe parámetros por POST y la acción loaivps devuelve los tipos de VPS disponibles para la cuenta.

¿Qué necesito para probar la API v19 de TaiVPS sin comprar nada?

Necesitás una cuenta de TaiVPS y tu propio auth_token. La petición loaivps es de solo lectura, así que no hace falta intentar una compra ni tocar un servidor para confirmar que la conexión anda. Eso la hace buena para un primer chequeo.

• Cuenta y token propios. La guía de dev.to pide el token de tu cuenta, no uno prestado.
• Token fuera de la vista. Nada de código, posts ni capturas de pantalla con el token a la vista.
• Endpoint v19. https://taivps.net/api/v19, con los parámetros en el body del POST.

Ojo con las capturas: cuando se pega un recorte en un ticket o en un chat, es fácil que el token quede visible sin que nadie lo note. Conviene revisar la imagen antes de compartirla.

¿Cómo es la petición cURL para listar los tipos de VPS?

Es un POST a https://taivps.net/api/v19 con dos campos de formulario: auth_token y action=loaivps. Este es el comando tal como lo muestra la fuente:

curl --request POST \
 --url "https://taivps.net/api/v19" \
 --form "auth_token=YOUR_TOKEN" \
 --form "action=loaivps"

YOUR_TOKEN es un marcador. La guía indica reemplazarlo por tu token en el entorno de ejecución y no subir el real a Git, a un workspace público de Postman ni a comentarios.

Una adaptación nuestra (no está en la fuente y no la probamos) para no escribir el token en el comando, en bash:

export TAIVPS_TOKEN="pegá_acá_tu_token"
curl --request POST \
 --url "https://taivps.net/api/v19" \
 --form "auth_token=$TAIVPS_TOKEN" \
 --form "action=loaivps"

Si el export queda en el historial de la terminal, el problema se mudó de lugar (spoiler: no se resolvió). En un script versionado, leé la variable desde un archivo .env que esté en .gitignore.

Si trabajás en Windows con PowerShell, tené en cuenta que curl es un alias de otro comando (Invoke-WebRequest) y no acepta las mismas opciones. Esta variante, también sin probar, llama explícitamente al ejecutable y lee el token de una variable de entorno de la sesión:

$env:TAIVPS_TOKEN = "pegá_acá_tu_token"
curl.exe --request POST `
 --url "https://taivps.net/api/v19" `
 --form "auth_token=$env:TAIVPS_TOKEN" `
 --form "action=loaivps"

¿Qué devuelve loaivps en la API de TaiVPS y sirve como lista fija de planes?

Devuelve un arreglo JSON de pares type y name, y no sirve como lista fija. Según la guía, la respuesta de la documentación es un ejemplo y no una lista cerrada de planes: la interfaz se arma con lo que responda la API en ese momento.

[
 { "type": "vps-gold", "name": "VPS Gold" },
 { "type": "vps-platinum", "name": "VPS Platinum" },
 { "type": "vps-vip", "name": "VPS VIP" }
]

Son tres entradas de ejemplo. Tu cuenta puede mostrar otras, menos o más.

Si hardcodeás esos tres valores en el front y mañana TaiVPS agrega, renombra o quita un tipo, vas a tener un selector que muestra opciones que ya no existen, o que esconde las nuevas, y nadie se entera hasta que un cliente reclama. Por eso conviene leer la lista en cada carga o cachearla con vencimiento corto.

Esta respuesta no trae precios ni configuración de hardware. Para eso hace falta otra consulta.

¿Cómo decidir qué hacer con la lista en tu integración?

La fuente solo cubre la llamada y su respuesta de ejemplo. Lo que sigue son criterios de diseño propios, derivados de que la lista es dinámica y de que loaivps solo devuelve type y name; no son una recomendación oficial de TaiVPS.

• Usá type como identificador y name como etiqueta. El type es lo que después le pasás a services; el name es lo que ve la persona. No los mezcles ni los reconstruyas a partir de texto.
• Si la lista cambia entre dos cargas, el selector tiene que poder actualizarse sin tocar código. Si en tu caso cada cambio exige un deploy, es señal de que quedó algo hardcodeado.
• Si un type guardado en tu base ya no aparece en la respuesta, tratalo como no disponible hasta confirmarlo en la documentación o con el proveedor, en lugar de seguir ofreciéndolo.
• Si la respuesta no tiene la forma esperada (no es un arreglo, o faltan type o name), no sigas a services: frená y revisá la documentación oficial.
• Si necesitás precios o configuraciones, no los busques acá: salen de services o de la tabla de planes vigente.

Ejemplo hipotético (no es un caso real ni una prueba): imaginá un panel interno de ventas de un revendedor que muestra un menú con los tipos de VPS. Si el menú se construye con tres opciones escritas a mano y el proveedor incorpora un cuarto tipo, el panel no lo ofrece y el equipo comercial no sabe que existe. Si en cambio el menú se arma con el resultado de loaivps (cacheado unos minutos, por ejemplo), la opción nueva aparece sola. Y si desaparece un tipo, el panel deja de ofrecerlo sin que nadie edite nada.

¿Cuál es el paso siguiente después de obtener el type?

Con el type en mano, usás action=services más el parámetro type para leer los planes de esa categoría. La fuente describe ese encadenamiento, pero no detalla la respuesta de services ni confirma todos sus parámetros, así que revisalos en la documentación oficial antes de codificar.

La guía también menciona una colección pública de Postman con tres ejemplos de solo lectura: tipos de servicio, planes VPS y sistemas operativos. Sirve para explorar sin escribir código, siempre que reemplaces el token en tu entorno y no lo guardes en un workspace compartido.

Un ejemplo hipotético, sin probar, de cómo se vería la segunda llamada si elegís vps-gold de la lista:

curl --request POST \
 --url "https://taivps.net/api/v19" \
 --form "auth_token=$TAIVPS_TOKEN" \
 --form "action=services" \
 --form "type=vps-gold"

¿Qué está confirmado, qué no y qué conviene evitar?

La guía describe el flujo a partir de la documentación pública y no lo ejecutó con tokens de clientes. Lo confirmado por la fuente es poco y concreto; el resto lo tenés que validar vos.

• Confirmado por la fuente: endpoint v19, POST con form data, action=loaivps de solo lectura, respuesta de ejemplo con type y name, y action=services con type como paso siguiente.
• No confirmado: qué cambió respecto de versiones anteriores de la API (la fuente no lo compara), cuáles son los tipos reales de tu cuenta hoy y el formato exacto de la respuesta de services.
• Operaciones a revisar antes de usar: compra, reinstalación, renovación y cancelación. La guía pide verificar parámetros e impacto en la documentación.
• Precios y configuración: tomalos de la tabla de planes vigente, porque pueden cambiar.

¿Probamos la llamada nosotros? No, y no hay mediciones propias en esta nota. Lo que sigue es una propuesta editorial, no un método de TaiVPS: ejecutá loaivps con tu token, confirmá que la respuesta sea un arreglo con type y name, y recién después pasá un type tomado de esa respuesta a services. Si algo no coincide con la documentación, frená ahí antes de tocar nada que escriba.

Errores comunes al probar la API

• Pegar el token real en un ejemplo. Puede pasar en issues, chats y colecciones de Postman públicas. Usá una variable de entorno y revisá el recorte antes de compartir.
• Hardcodear los tres tipos de la documentación. Son un ejemplo. Armá el selector con la respuesta actual.
• Buscar precios en la respuesta de loaivps. Solo trae type y name. Los valores salen de la tabla de planes vigente.
• Saltar a compra o cancelación para “probar rápido”. Para chequear la conexión alcanza con la consulta de solo lectura.
• Usar curl a secas en PowerShell. Ahí es un alias de otro comando; llamá a curl.exe.

Preguntas Frecuentes

¿Cómo listar los servicios VPS de TaiVPS con cURL?

Mandá un POST a https://taivps.net/api/v19 con --form "auth_token=TU_TOKEN" y --form "action=loaivps". La respuesta de ejemplo de la documentación es un arreglo de objetos con type y name.

¿Qué hace la acción loaivps de la API v19 de TaiVPS?

Devuelve los tipos de servicio VPS que tu cuenta puede usar. Es de solo lectura, así que no compra ni cambia ningún servidor.

¿Cómo probar una API de VPS sin comprar ni modificar nada?

Empezá por una acción de lectura. En TaiVPS, la guía propone loaivps, y la colección pública de Postman suma otros dos ejemplos de lectura: planes VPS y sistemas operativos.

¿Cómo enviar parámetros como form data con cURL en un POST?

Repetí la opción --form "campo=valor" una vez por parámetro. Es lo que usa la fuente; cURL arma el body como multipart/form-data, y la documentación de TaiVPS tendría que confirmar si acepta otros formatos.

¿Cómo guardo un auth_token sin subirlo a Git?

Guardalo en una variable de entorno o en un archivo .env incluido en .gitignore, y referencialo desde el comando. Evitá también dejarlo en capturas, comentarios y workspaces públicos de Postman, como advierte la fuente.

Conclusión

Lo que queda es una forma segura de verificar la API de TaiVPS: un POST de solo lectura, loaivps, que sirve para comprobar credenciales y conexión sin tocar tus servidores. La guía es corta y no cubre la respuesta de services, ni cambios frente a versiones previas, ni pruebas con cuentas reales.

Nuestra recomendación: corré loaivps con tu token en una variable de entorno, armá la interfaz con la respuesta y no con los tres ejemplos, y leé la documentación oficial antes de tocar compra, renovación o cancelación.

Fuentes

• TaiVPS API v19: liệt kê dịch vụ VPS bằng cURL – guía publicada en dev.to el 9 de octubre de 2026