Modelo de Solicitação de Integração API

Para quem é este modelo

Solicitações de integração API são onde DevRel encontra BD de parceiros e planejamento de capacidade de engenharia. O developer quer construir algo específico contra a sua API; o time de plataforma precisa saber o que estão construindo (caso de uso), quanta carga vai gerar (implicações de rate limit e cota), quais escopos OAuth e acesso a dados precisam (revisão de segurança), e se a integração vai para uma listagem em marketplace (product marketing e fluxo de aprovação). Este modelo estrutura o intake técnico em si — tipo de integração (REST API, GraphQL, assinaturas webhook, OAuth, download de SDK, data export, operações em bulk), descrição do caso de uso (o campo mais diagnóstico de se isso é uma parceria real ou alguém explorando), volume de requests esperado por mês (direciona a conversa de tier de rate limit e elegibilidade de tier de preço), requisitos específicos (escopos custom, IP allowlisting, infra dedicada, certificações de conformidade), certificações de segurança e conformidade que o developer traz (SOC 2 Type II, ISO 27001, LGPD certified, ENS para Espanha, HIPAA Business Associate Agreement para saúde), e o path de listagem (marketplace público, partner-only, integração embedada no cliente, uso interno). É o intake DevRel estruturado que seu time de plataforma usa antes da call de discovery técnico, não o genérico 'fale com developer relations' que cai em uma caixa compartilhada e é respondido com 'por favor confira os docs públicos da API' quando o developer tem uma pergunta específica que os docs não cobrem. Usado por plataformas SaaS API-first, processadores de pagamento, APIs de comunicação (Twilio, Vonage, MessageBird, Take Blip BR), plataformas CRM com ecossistema de developers (Salesforce AppExchange, HubSpot Marketplace, Pipedrive Marketplace), e qualquer produto rodando em Stripe Connect, Plaid, Stripe Atlas, Auth0, Clerk, Workato, n8n, Make, Zapier ou Tray.io.

Da solicitação do developer à call de discovery técnico em um fluxo estruturado

O developer ou parceiro envia o formulário com nome de contato, e-mail corporativo, nome da empresa e website (auto-enriquecido contra provedores B2B padrão para porte, indicadores de stack do BuiltWith / Wappalyzer, e histórico anterior de integração com sua plataforma se houver). O tipo de integração captura o que querem fazer — REST API para operações síncronas de leitura/escrita, GraphQL para queries complexas contra seu grafo de objetos, assinaturas webhook para fluxos event-driven (os mais complexos operacionalmente do ponto de vista de entrega e retry), OAuth para fluxos de autorização do end-user (que dispara a revisão de escopos-e-tela-de-consentimento), download de SDK para uso de client-library (que determina se você envia suporte para a linguagem deles), data export para extração em bulk (que tem implicações para rate limits e pode exigir um pipeline de export offline). A descrição do caso de uso é o campo mais diagnóstico — uma descrição específica de 5 frases diz ao time de plataforma que isso é uma oportunidade real de parceria que vale uma call de discovery técnico; uma descrição vaga de 1 frase diz que é exploratório e deve receber o link dos docs mais um template de follow-up. O volume de requests esperado por mês é o sinal de tier de rate limit — abaixo de 10K requests/mês é free-tier; 10K-1M é starter ou builder tier; 1M-100M é growth ou business tier; 100M+ é enterprise tier com rate limits custom e possivelmente infraestrutura dedicada. Requisitos específicos é o catch-all para as restrições técnicas que importam ao developer — escopos OAuth custom, requisito de IP allowlisting, tenant dedicado, residência regional de dados (apenas UE, apenas Brasil, apenas região SOC-2-restrita), certificações de conformidade (BAA para saúde sob HIPAA, DPA sob RGPD/LGPD, controles aduaneiros/exportação para escopos ITAR/EAR). Ao enviar, o fluxo auto-roteia — solicitações high-fit/high-volume vão para o líder do time de plataforma com um link de calendário de discovery; medium-fit vão para a fila de intake DevRel com links de documentação e um template de follow-up; perguntas exploratórias óbvias recebem a resposta template 'confira nossos docs públicos em docs.suaempresa.com mais a comunidade de developers no Slack/Discord'. Para solicitações com implicações de escopo OAuth ou segurança, o fluxo auto-cc o time de segurança para revisão paralela. Para solicitações destinadas a listagem em marketplace (Salesforce AppExchange, HubSpot Marketplace, Shopify App Store, Atlassian Marketplace, Zapier Apps Marketplace, RD Station Marketplace), o fluxo cria a tarefa de preparação de aplicação de marketplace na fila apropriada de product marketing.

O que está incluído

Cada campo existe porque algum time de plataforma se queimou pela sua ausência — geralmente no incidente de rate limit onde um developer que disse 'vamos enviar talvez 100 requests/dia' estava fazendo 50K/hora de um script de batch mal configurado, ou na revisão de segurança onde o developer queria escopos OAuth que incluíam read-on-all-customers mas nunca explicou por quê.

Plataformas que usam formulários de solicitação de integração API

• Plataformas SaaS API-first

  Stripe, Twilio, Plaid, Vonage, MessageBird, Auth0, Clerk, Algolia, Pusher, PubNub, Mux, AssemblyAI, OpenAI, Anthropic — as empresas API-first cujo relacionamento primário com developers é via a própria API. O formulário estrutura as perguntas inbound de developers além do que os docs públicos cobrem, captura os sinais de volume que direcionam a conversa de tier de preço, e roteia para DevRel para experiências de developer high-touch (rate limits custom, suporte dedicado, programas design-partner, acesso beta a API). Equivalentes brasileiros e latino-americanos: Pagar.me, Mercado Pago, Iugu, Asaas, Stark Bank, Pagseguro APIs, Hotmart APIs, Take Blip (chatbot/conversation API), Zenvia, RD Station APIs.

• Plataformas marketplace com ecossistemas de developers

  Salesforce AppExchange, HubSpot Marketplace, Shopify App Store, Atlassian Marketplace, Notion API integrations, Slack App Directory, Zoom Apps Marketplace, Microsoft AppSource — plataformas que dependem de developers terceiros construindo apps que se integram com a plataforma core. O formulário captura o intent de listagem (marketplace público vs. partner-only privado vs. integração embedada no cliente), que determina se o developer precisa passar pelo processo formal de revisão de marketplace ou pode usar o caminho self-serve de partner-developer. Para plataformas brasileiras (RD Station Marketplace, Conta Azul Integrations, Omie Marketplace, Bling Marketplace, Sankhya Marketplace), o mesmo padrão aplica com o ecossistema local de developers.

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

  Empresas mid-to-large com plataformas internas de developer onde outros times internos solicitam acesso a APIs de plataforma para novos builds de produto. O formulário captura o contexto do time interno — qual business unit está pedindo, qual é o valor de negócio, quais são os requisitos de carga e confiabilidade, quais são as restrições de segurança e conformidade. Substitui o intake de ticket Jira / DM de Slack com captura estruturada que o time de plataforma pode triar e priorizar contra o roadmap da plataforma. Para empresas brasileiras com times de plataforma interna (Itaú DevPortal, Mercado Livre Developer Platform, Banco do Brasil DevPortal para open banking, Magazine Luiza Tech Platform, Globo APIs), o mesmo intake estruturado.

• APIs de pagamentos e fintech

  Stripe, Adyen, Checkout.com, Square, PayPal Braintree, Klarna, Affirm, Wise, Plaid, Plaid Identity, MX, Yodlee, Truelayer, Salt Edge — APIs de pagamentos e fintech onde solicitações de integração vêm com implicações de conformidade regulatória (escopo PCI-DSS, PSD2 Strong Customer Authentication, licenciamento de money-transmitter por estado nos EUA, regulamentações BCB para Brasil com Pix e Open Finance, regulamentações Banco de España para Espanha). O campo de certificações-de-conformidade do formulário captura o que o developer traz para a mesa, o campo de caso de uso revela se são uma entidade regulada ou um operador passthrough, e o campo de requisitos específicos mostra o fluxo SCA/3DS/Pix que precisam suportar. Brasileiros: Pagar.me, Mercado Pago, Pagseguro, Stone APIs, Cielo APIs, Stark Bank, Iugu, Asaas, Vindi, Juno, dock, EBANX.

• APIs de comunicação (CPaaS) e plataformas conversacionais

  Twilio, Vonage, MessageBird, Plivo, Bandwidth, Sinch, Take Blip (BR), Yalo (LATAM), Trengo, Zenvia (BR), Movidesk APIs, Octadesk APIs — provedores CPaaS onde solicitações de integração vão de 'quero enviar 100 SMS/mês' a 'estou construindo um app de 10M usuários em cima da sua infra de voz'. O campo de volume esperado do formulário é o sinal de triagem mais importante porque a mesma superfície API serve aos dois extremos do espectro, com expectativas muito diferentes de preço, suporte e SLA. O campo de caso de uso também captura as implicações de comunicações reguladas (escopo HIPAA para voz de saúde, TCPA para outbound dos EUA, LGPD para Brasil, Lei do Marco Civil para dados de telecom, requisitos de prova de opt-in).

• APIs de Open Banking e Open Finance

  PSD2 na Europa, Open Banking UK, Open Finance Brasil (Resolução BCB 4.949), e as iniciativas paralelas no México (CNBV), Argentina, Austrália, Canadá — os ecossistemas API regulamentariamente-mandatados que empresas fintech, neobancos e agregadores consomem. O formulário captura o status de entidade regulada do solicitante (TPP sob PSD2, AISP/PISP sob Open Banking UK, Iniciador de Pagamentos sob Brasil Open Finance, Account Information Service Provider sob UK Open Banking, Instituição de Pagamento Eletrônico sob BCB), as certificações (eIDAS QWAC/QSeal para Europa, autorização BCB para Brasil — Resolução 80, Resolução 86 — autorização Banco de España para Espanha), e o caso de uso (agregação de contas, iniciação de pagamentos, verificação de identidade, decisioning de crédito, scoring). O intake estruturado é o que o time de plataforma usa para validar a postura de conformidade regulatória antes de conceder acesso a API de produção.

Adapte à sua plataforma API

Cada plataforma API tem suas próprias convenções de developer-relations. Configure as opções de tipo de integração para combinar com a superfície da sua plataforma — REST API, GraphQL, webhooks, OAuth (com seletor de escopo), SDK em linguagens específicas (Python, JavaScript/TypeScript, Go, Ruby, PHP, Java, C#, Swift, Kotlin), data export, operações em bulk, streams WebSocket em tempo real, gRPC para cenários internos de alto volume. Configure os tiers de volume para combinar com suas definições de tier de rate limit e de preço — abaixo de 10K/mês tipicamente é free tier; 10K-1M é starter; 1M-100M é growth; 100M+ é enterprise com rate limits custom. Configure o seletor de escopo OAuth para expor seus escopos inline para que developers possam identificar exatamente o que precisam (e para que a revisão de segurança possa antecipar o sprawl de escopo 'precisamos read-on-all-customers' que vira um incidente de segurança). Configure o campo de certificações-e-conformidade com o que sua plataforma exige — SOC 2 Type II para integrações enterprise, ISO 27001 para alguns clientes UE, LGPD certified para clientes brasileiros, ENS (Esquema Nacional de Seguridad) para setor público espanhol, HIPAA BAA para escopos de saúde, certificação PCI-DSS para escopos de pagamento. Configure o campo de path-de-listagem com a estrutura de marketplace da sua plataforma — listagem pública (revisão completa de marketplace), partner-only (revisão de programa interno de partner), integração embedada (específica do cliente, sem listagem), uso interno (apenas time de desenvolvimento). Integre com sua stack de developer-relations — ReadMe para hosting de docs, Mintlify ou Apidog para docs API modernos, Postman para compartilhamento de coleções, Stoplight para design de API, Speakeasy ou Stainless para geração de SDK, ReadMe Dev Dash ou Moesif ou Treblle para analytics de API, Discord ou Slack Community ou Common Room para comunidade de developers. Para plataformas rodando aprovações de marketplace através de processos dedicados (Salesforce AppExchange, HubSpot Marketplace), integre o envio do formulário com o fluxo de aplicação de marketplace. Para plataformas com programas de cliente regulado (HIPAA para APIs de saúde, PCI-DSS para APIs de pagamento, LGPD ou RGPD para APIs de dados sensíveis), a seção de conformidade do formulário captura as atestações upstream que o developer traz.

Perguntas frequentes sobre solicitações de integração API

Modelos relacionados