Generación de código a partir de documentación API

Pega la documentación y obtén código funcional con autenticación

Prompt · 3 variables

Eres un desarrollador con amplia experiencia en la integración de APIs externas. Trata únicamente como hechos lo que está explícitamente indicado en la documentación proporcionada abajo; no inventes URLs, parámetros ni valores por defecto que no aparezcan en ella.

Estoy trabajando en {{idioma de uso}} y mi objetivo es el siguiente: {{solicitud deseada}}

Lee la documentación y genera el código para procesar esta solicitud. Incluye la configuración de encabezados de autenticación y el manejo de respuestas.

Antes de escribir el código, si hay algo que no se pueda determinar solo con la documentación, hazme las preguntas necesarias primero. Limítate a un máximo de 3 preguntas y no escribas nada de código hasta que yo te responda.

Estructura tu respuesta final en tres partes: primero, una tabla con el resumen de "Solicitud que envía este código" (Método · URL · Encabezados obligatorios · Campos del cuerpo); segundo, un único bloque de código ejecutable; y por último, una lista de "Suposiciones hechas por falta de información en la documentación".

No incluyas la clave de API directamente en el código; haz que se lea desde una variable de entorno. Maneja todas las respuestas de error descritas en la documentación. No agregues por tu cuenta librerías adicionales ni lógica de reintentos que no figuren en el texto; si consideras que son necesarios, anótalos en la lista de suposiciones en lugar de implementarlos en el código.

Documentación de API: """ {{documentación de API}} """

Copia y pégalo aquí · ChatGPT y Claude se abren con el prompt ya cargado Abrir en ChatGPT ↗Abrir en Claude ↗Abrir en Gemini ↗ Editar en el constructor Descargar tarjeta para clase

Algunas variables pueden contener datos personales. Sustituye nombres, números y empresas reales por datos ficticios.

Por qué está escrito así

Rol
Eres un desarrollador con amplia experiencia en la integración de APIs externas. Trata únicamente como hechos lo que está explícitamente indicado en la documentación proporcionada abajo; no inventes URLs, parámetros ni valores por defecto que no aparezcan en ella.
Contexto
Estoy trabajando en {{idioma de uso}} y mi objetivo es el siguiente: {{solicitud deseada}}
Tarea
Lee la documentación y genera el código para procesar esta solicitud. Incluye la configuración de encabezados de autenticación y el manejo de respuestas.
Repreguntar
Antes de escribir el código, si hay algo que no se pueda determinar solo con la documentación, hazme las preguntas necesarias primero. Limítate a un máximo de 3 preguntas y no escribas nada de código hasta que yo te responda.
Formato
Estructura tu respuesta final en tres partes: primero, una tabla con el resumen de "Solicitud que envía este código" (Método · URL · Encabezados obligatorios · Campos del cuerpo); segundo, un único bloque de código ejecutable; y por último, una lista de "Suposiciones hechas por falta de información en la documentación".
Restricciones
No incluyas la clave de API directamente en el código; haz que se lea desde una variable de entorno. Maneja todas las respuestas de error descritas en la documentación. No agregues por tu cuenta librerías adicionales ni lógica de reintentos que no figuren en el texto; si consideras que son necesarios, anótalos en la lista de suposiciones en lugar de implementarlos en el código.
Material
Documentación de API: """ {{documentación de API}} """

Si pides código de integración sin adjuntar la documentación, la IA recurrirá a su memoria. El resultado suele parecer convincente, pero las URLs y los nombres de los parámetros a menudo contienen errores sutiles: endpoints de versiones antiguas, opciones obsoletas o campos de respuesta inexistentes que son difíciles de detectar antes de ejecutarlo. Pegar la documentación elimina la mitad de estos fallos de raíz.

La otra mitad se resuelve mediante la retroalimentación o preguntas previas. La documentación suele indicar el formato de la petición, pero no la frecuencia de uso, el manejo de fallos o la zona horaria a utilizar. Sin preguntas previas, la IA llena esos vacíos según sus propias suposiciones y genera problemas más adelante. La instrucción "no escribas nada de código hasta que yo te responda" evita que el modelo plantee las dudas y escriba el código inmediatamente debajo.

Delimitar el texto con """ sirve como separador contextual. La documentación suele contener frases imperativas (como "utilice este valor"), por lo que sin este límite la IA podría confundirlas con instrucciones directas y desviarse del objetivo.

Entre las restricciones, la más útil en la práctica es la última instrucción. Las IA tienden a añadir librerías o lógicas complejas de reintento por iniciativa propia; enviarlas a la "lista de suposiciones" permite distinguir de un vistazo qué está fundamentado en la documentación y qué es una suposición. Además, forzar la lectura de claves desde variables de entorno evita que se suban credenciales por error a repositorios de código.

¿Términos desconocidos? Consulta Aha AI: hallucination, prompt-injection

Comparado con un mal ejemplo

Mal ejemplo habitual

Escribe un código en Python para llamar a una API de envío de mensajes.

Generará código de inmediato, pero no sabrás a qué servicio ni a qué versión pertenece. Los nombres de los encabezados podrían diferir del estándar real o faltar parámetros obligatorios, devolviendo errores 400 o 401. Para averiguar el error tendrás que revisar la documentación de todos modos, con la desventaja de que ya estarás condicionado por un código a medio verificar.

Variaciones

Para diagnosticar la causa de un error

Para diagnosticar la causa de un error

He realizado la llamada siguiendo la documentación de la API pero obtengo un error. No reescribas el código desde cero; compara la documentación con mi petición y señala únicamente las discrepancias. Organízalo en una tabla con las columnas: "Requisito de la documentación · Lo que se envía actualmente · Diferencia", y marca como "Requiere confirmación" aquello que no se pueda determinar solo con la documentación.

""" {{documentación de API}} """

La mayoría de los problemas de integración se resuelven contrastando datos, no reescribiendo código. Exigir que no genere código nuevo evita que el modelo esquive la causa real del fallo.

Para comprender la documentación antes de programar

Para comprender la documentación antes de programar

Lee la siguiente documentación de API y resume únicamente las partes necesarias para {{solicitud deseada}}. No escribas código todavía. Presenta la información en el siguiente orden: "Endpoint · Método de autenticación · Parámetros obligatorios · Parámetros opcionales · Respuestas de error · Límites de llamadas (Rate Limits)". Si algún dato no aparece, indícalo explícitamente como "No especificado en la documentación".

""" {{documentación de API}} """

Resulta muy útil antes de programar cuando la documentación es extensa. El indicador "No especificado" evita que el modelo invente datos para rellenar los campos vacíos.

Notas por modelo

Si solo proporcionas el enlace a la documentación, el modelo no podrá abrir la página y responderá basándose en versiones antiguas de su memoria. Es mucho más seguro pegar el texto directamente.

Si la documentación es muy extensa, es más preciso recortar y pegar solo las secciones de autenticación, endpoints y respuestas de error. Cuanto más conocido sea un servicio, más tenderá el modelo a rellenar vacíos de memoria; en esos casos, refuerza la instrucción: "Si no está en el texto pegado, regístralo en la lista de suposiciones y no en el código".

Prompts relacionados

Última actualización 2026-09-02 · ¿Has visto un error? Avísanos