Descripción general de las APIs de Cursor
Cursor ofrece varias APIs para acceder mediante programación a los datos de tu equipo, los agentes de programación con IA y la analítica.
API disponibles
| API | Descripción | Disponibilidad |
|---|---|---|
| Admin API | Gestiona miembros del equipo, configuración, datos de consumo, gastos y acceso a modelos. Crea paneles y herramientas de supervisión personalizados. | Equipos Enterprise |
| Analytics API | Obtén información detallada sobre el consumo de Cursor del equipo, las métricas de IA, los usuarios activos y el consumo de modelos. | Equipos Enterprise |
| API de Seguimiento de Código con IA | Haz un seguimiento de las contribuciones de código generado por IA a nivel de commit y cambio para fines de atribución y analítica. | Equipos Enterprise |
| Bugbot API | Activa revisiones de Bugbot y obtén analítica de cada revisión. | Equipos Enterprise |
| API de Cloud Agents | Crea y gestiona de forma programática agentes de programación con IA para flujos de trabajo automatizados y generación de código. | Beta (Todos los planes) |
| Origin API | Trabaja con repositorios, commits, comprobaciones, pull requests e instalaciones de aplicaciones de Origin. | Alfa |
| SDK de TypeScript | Ejecuta agentes de Cursor desde TypeScript con una interfaz para runtimes locales y en la nube. | Todos los usuarios |
| SDK de Python | Ejecuta agentes de Cursor desde Python con clientes síncronos y asíncronos para runtimes locales y en la nube. | Todos los usuarios |
| SDK Bridge | Crea SDK de agentes en otros lenguajes basados en el protocolo bridge abierto y binarios independientes. | Todos los usuarios |
La API de Cloud Agents y los SDK ejecutan flujos de trabajo de agentes de Cursor (contexto del espacio de trabajo, herramientas, comandos y ediciones). No son una API independiente de inferencia de modelos ni de completado de chat. Cursor Router selecciona modelos para esas ejecuciones de agentes cuando usas Auto / auto-smart; consulta Cursor Router en el SDK de TypeScript o el SDK de Python.
Autenticación
Todas las API de Cursor admiten autenticación básica. La API de Cloud Agents también admite tokens Bearer; elige la opción que resulte más sencilla para tu cliente HTTP.
Autenticación básica
Usa tu clave de API como nombre de usuario para la autenticación básica (deja la contraseña en blanco):
curl https://api.cursor.com/teams/members \ -u YOUR_API_KEY:O establezca directamente el encabezado Authorization:
Authorization: Basic {base64_encode('YOUR_API_KEY:')}Autenticación con token Bearer (API de Cloud Agents)
La API de Cloud Agents también acepta encabezados Authorization: Bearer <key>. Ambos métodos funcionan de forma idéntica; usa el que resulte más sencillo con tu cliente HTTP:
curl https://api.cursor.com/v1/me \ -H "Authorization: Bearer YOUR_API_KEY"Creación de claves de API
Los administradores de equipo pueden crear y gestionar claves de API desde la página Claves de API del Panel de control.
Admin API y API de Seguimiento de Código con IA
- Ve a cursor.com/dashboard → Claves de API
- Haz clic en Nueva clave de API
- Asigna a tu clave un nombre descriptivo (p. ej., "Integración del panel de control de consumo")
- Copia la clave generada de inmediato. No podrás volver a verla
Formato de la clave: crsr_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Alcance requerido: admin:*
Analytics API
Genera una clave de API en Cursor Panel de control → clave de API.
API de Cloud Agents
Crea una clave de API de usuario en Cursor Panel de control → clave de API o usa una clave de API de cuenta de servicio en los ajustes de equipo.
Las claves de API están vinculadas a tu organización y todos los administradores pueden consultarlas. No se ven afectadas por el estado de la cuenta del creador original.
Límites de uso
Todas las API aplican límites de uso para garantizar un uso equitativo y la estabilidad del sistema. Los límites de uso se aplican por equipo y se restablecen cada minuto.
Límites de uso por API
| API | Tipo de endpoint | Límite de uso |
|---|---|---|
| Admin API | La mayoría de los endpoints | 20 solicitudes/minuto |
| Admin API | /teams/filtered-usage-events y /organizations/filtered-usage-events | 60 solicitudes/minuto |
| Admin API | /teams/user-spend-limit | 250 solicitudes/minuto |
| Analytics API | La mayoría de los endpoints a nivel de equipo | 100 solicitudes/minuto |
| Analytics API | /analytics/team/conversation-insights | 20 solicitudes/minuto |
| Analytics API | Endpoints por usuario | 50 solicitudes/minuto |
| API de Seguimiento de Código con IA | Todos los endpoints | 20 solicitudes/minuto por endpoint |
| Bugbot API | /bugbot/review | 30 solicitudes/minuto |
| Bugbot API | /bugbot/review con dryRun: true | 10 solicitudes/minuto (además del límite de activación) |
| API de Cloud Agents | Todos los endpoints | Limitación de uso estándar |
Respuesta de límite de uso
Si superas el límite de uso, recibirás una respuesta 429 Too Many Requests:
{ "error": "Too Many Requests", "message": "Rate limit exceeded. Please try again later."}Almacenamiento en caché
Varias API admiten el almacenamiento en caché HTTP con ETags para reducir el consumo de ancho de banda y mejorar el rendimiento.
API compatibles
- Analytics API: Todos los endpoints (tanto a nivel de equipo como por usuario) admiten el almacenamiento en caché HTTP
- API de Seguimiento de Código con IA: Los endpoints admiten el almacenamiento en caché HTTP
Cómo funciona el almacenamiento en caché
- Solicitud inicial: Realiza una solicitud a cualquier endpoint compatible
- La respuesta incluye un ETag: La API devuelve una cabecera
ETagen la respuesta - Solicitudes posteriores: Incluye el valor de
ETagen una cabeceraIf-None-Match - 304 Sin modificaciones: Si los datos no han cambiado, recibirás una respuesta
304 Not Modifiedsin cuerpo
Ejemplo
# Solicitud inicialcurl -X GET "https://api.cursor.com/analytics/team/dau" \ -H "Authorization: Bearer YOUR_API_KEY" \ -D headers.txt# La respuesta incluye: ETag: "abc123xyz"# Solicitud posterior con ETagcurl -X GET "https://api.cursor.com/analytics/team/dau" \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "If-None-Match: \"abc123xyz\""# Devuelve 304 Not Modified si los datos no han cambiadoDuración de la caché
- Duración de la caché: 15 minutos (
Cache-Control: public, max-age=900) - Las respuestas incluyen una cabecera
ETag - Incluye la cabecera
If-None-Matchen las solicitudes posteriores para recibir un304 Not Modifiedcuando los datos no hayan cambiado
Ventajas
- Reduce el consumo de ancho de banda: las respuestas 304 no incluyen cuerpo
- Respuestas más rápidas: evita procesar datos sin cambios
- No afecta a los límites de uso: las respuestas 304 no cuentan para los límites de uso
- Mejor rendimiento: especialmente útil para endpoints consultados con frecuencia
Mejores prácticas
1. Implementa el retroceso exponencial
Cuando recibas una respuesta 429, espera antes de volver a intentarlo, aumentando el tiempo de espera:
import timeimport requestsdef make_request_with_backoff(url, headers, max_retries=5): for attempt in range(max_retries): response = requests.get(url, headers=headers) if response.status_code == 429: # Espera exponencial: 1 s, 2 s, 4 s, 8 s, 16 s wait_time = 2 ** attempt print(f"Rate limited. Waiting {wait_time}s before retry...") time.sleep(wait_time) continue return response raise Exception("Max retries exceeded")2. Distribuya las solicitudes a lo largo del tiempo
Distribuya las llamadas a la API a lo largo del tiempo en lugar de hacer solicitudes en ráfaga:
- Programe trabajos en lote para que se ejecuten a intervalos distintos
- Añada pausas entre solicitudes al procesar conjuntos de datos grandes
- Use sistemas de colas para reducir los picos de tráfico
3. Aprovecha el almacenamiento en caché
Para Analytics API y la API de Seguimiento de Código con IA:
Estas API admiten almacenamiento en caché HTTP con ETags. Consulta la sección Almacenamiento en caché anterior para saber cómo usar ETags para reducir el consumo de ancho de banda y evitar solicitudes innecesarias.
Ventajas principales:
- Reduce el consumo de ancho de banda
- Respuestas más rápidas cuando los datos no han cambiado
- No consume límites de uso (para respuestas 304)
Usa atajos de fecha (7d, 30d) en lugar de marcas de tiempo para mejorar la compatibilidad con el almacenamiento en caché en Analytics API.
4. Supervisa tu consumo
Haz un seguimiento de tus patrones de solicitudes para mantenerte dentro de los límites:
- Registra las marcas de tiempo de las llamadas a la API y los códigos de respuesta
- Configura alertas para las respuestas 429
- Supervisa las tendencias de consumo diarias y semanales
- Ajusta los intervalos de sondeo según las necesidades reales
5. Procesa en lote de forma eficiente
Para endpoints con paginación:
- Usa tamaños de página adecuados para obtener más datos por solicitud
- Para endpoints por usuario de Analytics API: usa el parámetro
userspara filtrar usuarios específicos - Para la extracción de grandes volúmenes de datos: usa endpoints CSV cuando estén disponibles (transmiten los datos de forma eficiente)
6. Consulta a intervalos adecuados
No consultes con demasiada frecuencia endpoints que se actualizan poco:
- Admin API
/teams/daily-usage-data: Consulta como máximo una vez por hora (los datos se agregan cada hora) - Admin API
/teams/filtered-usage-events: Consulta como máximo una vez por hora (los datos se agregan cada hora) - Admin API
/organizations/pooled-usage: Consulta como máximo una vez por hora (los datos se agregan cada hora) - Admin API
/organizations/filtered-usage-events: Consulta como máximo una vez por hora (los datos se agregan cada hora) - Analytics API: Usa atajos de fecha (
7d,30d) para mejorar el almacenamiento en caché - API de Seguimiento de Código con IA: Los datos se incorporan casi en tiempo real, pero basta con consultar cada pocos minutos
7. Gestiona los errores adecuadamente
Implementa un manejo adecuado de errores para todas las llamadas a la API:
async function fetchAnalytics(endpoint) { try { const response = await fetch(`https://api.cursor.com${endpoint}`, { headers: { 'Authorization': `Basic ${btoa(API_KEY + ':')}` } }); if (response.status === 429) { // Límite de uso alcanzado: implementar espera progresiva throw new Error('Rate limit exceeded'); } if (response.status === 401) { // Clave de API no válida throw new Error('Authentication failed'); } if (response.status === 403) { // Permisos insuficientes throw new Error('Enterprise access required'); } if (!response.ok) { throw new Error(`API error: ${response.status}`); } return await response.json(); } catch (error) { console.error('API request failed:', error); throw error; }}Respuestas de error habituales
Todas las API usan códigos de estado HTTP estándar:
400 Solicitud incorrecta
Los parámetros de la solicitud no son válidos o faltan campos obligatorios.
{ "error": "Bad Request", "message": "Some users are not in the team"}401 No autorizado
Clave de API no válida o no proporcionada.
{ "error": "Unauthorized", "message": "Invalid API key"}403 Prohibido
Clave de API válida, pero sin permisos suficientes (p. ej., funciones Enterprise en un plan que no es Enterprise).
{ "error": "Forbidden", "message": "Enterprise access required"}404 No encontrado
El recurso solicitado no existe.
{ "error": "Not Found", "message": "Resource not found"}429 Demasiadas solicitudes
Se superó el límite de uso. Implemente un retroceso exponencial.
{ "error": "Too Many Requests", "message": "Rate limit exceeded. Please try again later."}500 Error interno del servidor
Error del servidor. Contacta con soporte si el problema persiste.
{ "error": "Internal Server Error", "message": "An unexpected error occurred"}