Plantilla de Solicitud de Integración API

Para quién es esta plantilla

Las solicitudes de integración API son donde DevRel se encuentra con BD de partners y con planificación de capacidad de ingeniería. El developer quiere construir algo específico contra tu API; el equipo de plataforma necesita saber qué están construyendo (caso de uso), cuánta carga generará (implicaciones de rate limit y cuota), qué scopes OAuth y acceso a datos necesitan (revisión de seguridad), y si la integración va a un listado en marketplace (product marketing y flujo de aprobación). Esta plantilla estructura el intake técnico en sí — tipo de integración (REST API, GraphQL, suscripciones webhook, OAuth, descarga de SDK, data export, operaciones en bulk), descripción del caso de uso (el campo más diagnóstico de si esto es un partnership real o alguien explorando), volumen de requests esperado al mes (dirige la conversación de tier de rate limit y la elegibilidad del tier de precio), requisitos específicos (scopes custom, IP allowlisting, infra dedicada, certificaciones de cumplimiento), certificaciones de seguridad y cumplimiento que trae el developer (SOC 2 Type II, ISO 27001, ENS para Esquema Nacional de Seguridad español, LGPD certified, HIPAA Business Associate Agreement para sanidad), y el path de listado (marketplace público, partner-only, integración embebida en cliente, uso interno). Es el intake DevRel estructurado que tu equipo de plataforma usa antes de la llamada de discovery técnico, no el genérico 'contacta con developer relations' que cae en una bandeja compartida y se contesta con 'por favor revisa los docs públicos de la API' cuando el developer tiene una pregunta específica que los docs no cubren. Usado por plataformas SaaS API-first, procesadores de pagos, APIs de comunicaciones (Twilio, Vonage, MessageBird), plataformas CRM con ecosistema de developers (Salesforce AppExchange, HubSpot Marketplace, Pipedrive Marketplace), y cualquier producto corriendo en Stripe Connect, Plaid, Stripe Atlas, Auth0, Clerk, Workato, n8n, Make, Zapier o Tray.io.

De solicitud de developer a llamada de discovery técnico en un flujo estructurado

El developer o partner envía el formulario con nombre de contacto, email corporativo, nombre de empresa y website (auto-enriquecido contra los proveedores B2B estándar para tamaño, indicadores de stack desde BuiltWith / Wappalyzer, e historial previo de integración con tu plataforma si existe). El tipo de integración captura qué quieren hacer — REST API para operaciones síncronas de lectura/escritura, GraphQL para queries complejas contra tu grafo de objetos, suscripciones webhook para flujos event-driven (los más complejos operacionalmente desde el punto de vista de delivery y retry), OAuth para flujos de autorización del end-user (que dispara la revisión de scopes-and-consent-screen), descarga de SDK para uso de client-library (que determina si envías soporte para su lenguaje), data export para extracción en bulk (que tiene implicaciones para rate limits y puede requerir un pipeline de export offline). La descripción del caso de uso es el campo más diagnóstico — una descripción específica de 5 frases le dice al equipo de plataforma que esto es una oportunidad de partnership real que merece una llamada de discovery técnico; una descripción vaga de 1 frase les dice que es exploratorio y debería recibir el link de docs más una plantilla de seguimiento. El volumen de requests esperado al mes es la señal de tier de rate limit — menos de 10K requests/mes es free-tier; 10K-1M es starter o builder tier; 1M-100M es growth o business tier; 100M+ es enterprise tier con rate limits custom y posiblemente infraestructura dedicada. Los requisitos específicos son el catch-all para las restricciones técnicas que le importan al developer — scopes OAuth custom, requisito de IP allowlisting, tenant dedicado, residencia regional de datos (solo UE, solo Brasil, solo región SOC-2-restringida), certificaciones de cumplimiento (BAA para sanidad bajo HIPAA, DPA bajo RGPD/LGPD, controles aduaneros/exportación para scopes ITAR/EAR). Al enviar, el flujo auto-enruta — solicitudes de high-fit/high-volume van al líder del equipo de plataforma con un link de calendario de discovery; medium-fit van a la cola de intake DevRel con links de documentación y una plantilla de seguimiento; preguntas exploratorias obvias reciben la respuesta plantilla 'revisa nuestros docs públicos en docs.tuempresa.com más la comunidad de developers en Slack/Discord'. Para solicitudes con implicaciones de scope OAuth o seguridad, el flujo auto-cc al equipo de seguridad para revisión paralela. Para solicitudes destinadas a un listado en marketplace (Salesforce AppExchange, HubSpot Marketplace, Shopify App Store, Atlassian Marketplace, Zapier Apps Marketplace), el flujo crea la tarea de preparación de solicitud de listado en marketplace en la cola apropiada de product marketing.

Qué incluye

Cada campo existe porque algún equipo de plataforma se ha quemado por su ausencia — normalmente en el incidente de rate limit donde un developer que dijo 'enviaremos quizás 100 requests/día' estaba haciendo 50K/hora desde un script de batch mal configurado, o en la revisión de seguridad donde el developer quería scopes OAuth que incluían read-on-all-customers pero nunca explicó por qué.

Plataformas que usan formularios de solicitud de integración API

• Plataformas SaaS API-first

  Stripe, Twilio, Plaid, Vonage, MessageBird, Auth0, Clerk, Algolia, Pusher, PubNub, Mux, AssemblyAI, OpenAI, Anthropic — las empresas API-first cuya relación primaria con developers es vía la propia API. El formulario estructura las preguntas inbound de developers más allá de lo que cubren los docs públicos, captura las señales de volumen que dirigen la conversación de tier de precio, y enruta a DevRel para las experiencias de developer high-touch (rate limits custom, soporte dedicado, programas design-partner, acceso beta a API). Equivalentes españoles y latinoamericanos: PaynoPain, Bizum APIs, Pagantis, Aplazame, Sequra; en Brasil: Pagar.me, Mercado Pago, Iugu, Asaas, Stark Bank, Hotmart APIs, Take Blip.

• Plataformas marketplace con ecosistemas de developers

  Salesforce AppExchange, HubSpot Marketplace, Shopify App Store, Atlassian Marketplace, Notion API integrations, Slack App Directory, Zoom Apps Marketplace, Microsoft AppSource — plataformas que dependen de developers terceros construyendo apps que se integran con la plataforma core. El formulario captura el intent de listado (marketplace público vs. partner-only privado vs. integración embebida en cliente), que determina si el developer necesita pasar por el proceso formal de revisión de marketplace o puede usar el path self-serve de partner-developer. Para plataformas españolas (Holded Marketplace, FacturaScripts Plugins) y brasileñas (RD Station Marketplace, Conta Azul Integrations, Omie Marketplace, Bling Marketplace), el mismo patrón aplica con el ecosistema local de developers.

• Equipos de plataforma interna (Platform Engineering / Developer Experience)

  Empresas mid-to-large con plataformas internas de developer donde otros equipos internos solicitan acceso a APIs de plataforma para nuevos builds de producto. El formulario captura el contexto del equipo interno — qué business unit pregunta, cuál es el valor de negocio, cuáles son los requisitos de carga y fiabilidad, cuáles son las restricciones de seguridad y cumplimiento. Sustituye el intake de ticket de Jira / DM de Slack con captura estructurada que el equipo de plataforma puede triajear y priorizar contra el roadmap de plataforma. Para empresas españolas y latinoamericanas con equipos de plataforma interna (Telefónica DevPortal, BBVA Open API, Banco Santander Developer Portal, Inditex Tech Developer Platform, La Liga DevHub), el mismo intake estructurado.

• APIs de pagos y fintech

  Stripe, Adyen, Checkout.com, Square, PayPal Braintree, Klarna, Affirm, Wise, Plaid, Plaid Identity, MX, Yodlee, Truelayer, Salt Edge — APIs de pagos y fintech donde las solicitudes de integración vienen con implicaciones de cumplimiento regulatorio (scope PCI-DSS, PSD2 Strong Customer Authentication, licencia de transmisor de dinero por estado en EE. UU., regulaciones del Banco de España para España con Bizum y SEPA Instant, regulaciones del BCB para Brasil con Pix y Open Finance). El campo de certificaciones-de-cumplimiento del formulario captura qué trae el developer a la mesa, el campo de caso de uso revela si son una entidad regulada o un operador passthrough, y el campo de requisitos específicos muestra el flujo SCA/3DS/Bizum/Pix que necesitan soportar.

• APIs de comunicaciones (CPaaS) y plataformas conversacionales

  Twilio, Vonage, MessageBird, Plivo, Bandwidth, Sinch, Take Blip (BR), Yalo (LATAM), Trengo, Zenvia (BR), Masvoz (España), Voipnet, Vozelia — proveedores CPaaS donde las solicitudes de integración van desde 'quiero enviar 100 SMS/mes' hasta 'estoy construyendo una app de 10M usuarios sobre tu infra de voz'. El campo de volumen esperado del formulario es la señal de triaje más importante porque la misma superficie API sirve a ambos extremos del espectro, con expectativas de pricing, soporte y SLA muy distintas. El campo de caso de uso también captura las implicaciones de comunicaciones reguladas (scope HIPAA para voz sanitaria, TCPA para outbound de EE. UU., LGPD para Brasil, LSSI para España con requisitos de prueba de opt-in).

• APIs Open Banking y Open Finance

  PSD2 en Europa, Open Banking UK, Open Finance Brasil (Resolução BCB 4.949), y las iniciativas paralelas en México (CNBV), Argentina, Australia, Canadá — los ecosistemas API regulatorios que las empresas fintech, neobancos y agregadores consumen. El formulario captura el estado de entidad regulada del solicitante (TPP bajo PSD2, AISP/PISP bajo Open Banking UK, Iniciador de Pagamentos bajo Open Finance Brasil, Entidad de Pago Híbrida bajo Banco de España), las certificaciones (eIDAS QWAC/QSeal para Europa, autorización BCB para Brasil, autorización del Banco de España para España), y el caso de uso (agregación de cuentas, iniciación de pagos, verificación de identidad, scoring de crédito). El intake estructurado es lo que el equipo de plataforma usa para validar la postura de cumplimiento regulatorio antes de conceder acceso a API de producción.

Adáptala a tu plataforma API

Cada plataforma API tiene sus propias convenciones de developer-relations. Configura las opciones de tipo de integración para que coincidan con la superficie de tu plataforma — REST API, GraphQL, webhooks, OAuth (con selector de scope), SDK en lenguajes específicos (Python, JavaScript/TypeScript, Go, Ruby, PHP, Java, C#, Swift, Kotlin), data export, operaciones en bulk, streams WebSocket en tiempo real, gRPC para escenarios internos de alto volumen. Configura los tiers de volumen para que coincidan con tus definiciones de tier de rate limit y de pricing — menos de 10K/mes típicamente es free tier; 10K-1M es starter; 1M-100M es growth; 100M+ es enterprise con rate limits custom. Configura el selector de scope OAuth para exponer tus scopes inline para que los developers puedan identificar exactamente lo que necesitan (y para que la revisión de seguridad pueda anticipar el sprawl de scope 'necesitamos read-on-all-customers' que se convierte en un incidente de seguridad). Configura el campo de certificaciones-y-cumplimiento con lo que tu plataforma requiere — SOC 2 Type II para integraciones enterprise, ISO 27001 para algunos clientes UE, LGPD certified para clientes brasileños, ENS (Esquema Nacional de Seguridad) para sector público español, HIPAA BAA para scopes sanitarios, certificación PCI-DSS para scopes de pagos. Configura el campo de path-de-listado con la estructura de marketplace de tu plataforma — listado público (revisión completa de marketplace), partner-only (revisión de programa interno de partner), integración embebida (específica del cliente, sin listado), uso interno (solo equipo de desarrollo). Integra con tu stack de developer-relations — ReadMe para hosting de docs, Mintlify o Apidog para docs API modernos, Postman para compartir colecciones, Stoplight para diseño de API, Speakeasy o Stainless para generación de SDK, ReadMe Dev Dash o Moesif o Treblle para analítica de API, Discord o Slack Community o Common Room para comunidad de developers. Para plataformas corriendo aprobaciones de marketplace a través de procesos dedicados (Salesforce AppExchange, HubSpot Marketplace), integra el envío del formulario con el flujo de aplicación a marketplace. Para plataformas con programas de cliente regulado (HIPAA para APIs sanitarias, PCI-DSS para APIs de pago, LGPD o RGPD para APIs de datos sensibles), la sección de cumplimiento del formulario captura las atestaciones upstream que trae el developer.

Preguntas frecuentes sobre solicitudes de integración API

Plantillas relacionadas