Back to all templates
DevRel & platform team intake

API Integration Request Form Template

Capture developer and partner integration requests with structured technical intake — integration type, use case, expected volume, OAuth scope, security posture, and specific requirements. Replaces the developers@ inbox where requests die between feature questions and the engineering on-call.

Free — included in every plan

API Integration Request Form Template

Live preview — try the fields below.

No fields to preview.

Who this template is for

API integration requests are where DevRel teams meet partner BD meets engineering capacity planning. The developer wants to build something specific against your API; the platform team needs to know what they are building (use case), how much load it will generate (rate limit and quota implications), what OAuth scopes and data access they need (security review), and whether the integration is going on a marketplace listing (product marketing and approval workflow). This template structures the technical intake itself — integration type (REST API, GraphQL, webhook subscriptions, OAuth, SDK download, data export, bulk operations), use case description (the most diagnostic field for whether this is a real partnership or someone exploring), expected request volume per month (drives the rate-limit-tier conversation and the pricing tier eligibility), specific requirements (custom scopes, IP allowlisting, dedicated infra, compliance attestations), security and compliance certifications the developer brings (SOC 2 Type II, ISO 27001, LGPD certified, ENS for Spain, HIPAA Business Associate Agreement for healthcare), and the listing path (public marketplace, partner-only, embedded customer integration, internal use). It is the structured DevRel intake your platform team uses before the technical discovery call, not the generic 'contact developer relations' link that lands in a shared inbox and gets answered with 'please check the public API docs' when the developer has a specific question that the docs do not address. Used by API-first SaaS platforms, payment processors, communications APIs (Twilio, Vonage, MessageBird, Take Blip BR), CRM platforms with developer ecosystems (Salesforce AppExchange, HubSpot Marketplace, Pipedrive Marketplace), and any product running on Stripe Connect, Plaid, Stripe Atlas, Auth0, Clerk, Workato, n8n, Make, Zapier, or Tray.io.

From developer request to technical discovery call in a structured flow

Developer or partner submits the form with contact name, work email, company name, and website (auto-enriched against the standard B2B providers for size, stack indicators from BuiltWith / Wappalyzer, and prior integration history with your platform if any). Integration type captures what they want to do — REST API for synchronous read/write operations, GraphQL for complex queries against your object graph, webhook subscriptions for event-driven workflows (the most operationally complex from a delivery and retry standpoint), OAuth for end-user authorization flows (which triggers the scopes-and-consent-screen review), SDK download for client-library use (which determines whether you ship support for their language), data export for bulk extraction (which has implications for rate limits and may require an offline export pipeline). Use case description is the most diagnostic field — a 5-sentence specific description tells the platform team this is a real partnership opportunity worth a technical discovery call; a 1-sentence vague description tells them this is exploratory and should get the docs link plus a follow-up template. Expected request volume per month is the rate-limit-tier signal — under 10K requests/month is free-tier; 10K-1M is starter or builder tier; 1M-100M is growth or business tier; 100M+ is enterprise tier with custom rate limits and possibly dedicated infrastructure. Specific requirements is the catch-all for the technical constraints the developer cares about — custom OAuth scopes, IP allowlisting requirement, dedicated tenant, regional data residency (EU-only, Brazil-only, SOC-2-region-restricted), compliance attestations (BAA for healthcare under HIPAA, DPA under GDPR/LGPD, customs/export controls for ITAR/EAR scopes). On submission, the workflow auto-routes — high-fit/high-volume requests go to the platform-team lead with a discovery-call calendar link; medium-fit go to the DevRel intake queue with documentation links and a follow-up template; obvious exploratory questions get the templated 'check our public docs at docs.yourcompany.com plus the developer Slack/Discord community' response. For requests with OAuth scope or security implications, the workflow auto-cc's the security team for parallel review. For requests destined for a marketplace listing (Salesforce AppExchange, HubSpot Marketplace, Shopify App Store, Atlassian Marketplace, Zapier Apps Marketplace), the workflow creates the marketplace-listing-application-prep task in the appropriate product-marketing queue.

What's included

Every field exists because some platform team has been burned by its absence — usually at the rate-limit incident where a developer who said 'we'll send maybe 100 requests/day' was actually doing 50K/hour from a misconfigured batch script, or at the security review where the developer wanted OAuth scopes that included read-on-all-customers but never explained why.

Platforms using API integration request forms

  • API-first SaaS platforms

    Stripe, Twilio, Plaid, Vonage, MessageBird, Auth0, Clerk, Algolia, Pusher, PubNub, Mux, AssemblyAI, OpenAI, Anthropic — the API-first companies whose primary developer relationship is via the API itself. The form structures the inbound developer-asks beyond what the public docs answer, captures the volume signals that drive the pricing tier conversation, and routes to DevRel for the high-touch developer experiences (custom rate limits, dedicated support, design-partner programs, beta API access). Brazilian and Latin American equivalents: Pagar.me, Mercado Pago, Iugu, Asaas, Stark Bank, Hotmart APIs, Take Blip (chatbot/conversation API).

  • Marketplace platforms with developer ecosystems

    Salesforce AppExchange, HubSpot Marketplace, Shopify App Store, Atlassian Marketplace, Notion API integrations, Slack App Directory, Zoom Apps Marketplace, Microsoft AppSource — platforms that depend on third-party developers building apps that integrate with the core platform. The form captures the listing intent (public marketplace vs. private partner-only vs. embedded customer integration), which determines whether the developer needs to go through the formal marketplace review process or can use the partner-developer self-serve path. For Brazilian platforms (RD Station Marketplace, Conta Azul Integrations, Omie Marketplace, Bling Marketplace), the same pattern applies with the local developer ecosystem.

  • Internal platform teams (Platform Engineering / Developer Experience)

    Mid-to-large companies with internal developer platforms where other internal teams request access to platform APIs for new product builds. The form captures internal-team context — which business unit is asking, what the business value is, what the load and reliability requirements are, what the security and compliance constraints are. Replaces the Jira ticket / Slack DM intake with structured capture that the platform team can triage and prioritize against the platform roadmap. For Brazilian and Spanish companies with internal platform teams (Itaú DevPortal, Mercado Livre Developer Platform, Banco do Brasil DevPortal for open banking, Telefónica DevPortal, BBVA Open API), the same structured intake.

  • Payments and fintech APIs

    Stripe, Adyen, Checkout.com, Square, PayPal Braintree, Klarna, Affirm, Wise, Plaid, Plaid Identity, MX, Yodlee, Truelayer, Salt Edge — payment and fintech APIs where integration requests come with regulatory compliance implications (PCI-DSS scope, PSD2 Strong Customer Authentication, US state money-transmitter licensing, BCB regulations for Brazil with Pix and Open Finance, Banco de España regulations for Spain). The form's compliance-certifications field captures what the developer brings to the table, the use-case field reveals whether they are a regulated entity or a passthrough operator, and the specific-requirements field surfaces the SCA/3DS/Pix flow they need to support.

  • Communications APIs (CPaaS) and conversation platforms

    Twilio, Vonage, MessageBird, Plivo, Bandwidth, Sinch, Take Blip (BR), Yalo (LATAM), Trengo, Zenvia (BR) — CPaaS providers where integration requests range from 'I want to send 100 SMS/month' to 'I am building a 10M-user app on top of your voice infrastructure.' The form's expected-volume field is the most important triage signal because the same API surface serves both ends of the spectrum, with very different pricing, support, and SLA expectations. The use-case field also captures the regulated-comms implications (HIPAA-scope voice for healthcare, TCPA for US outbound, LGPD for Brazil, opt-in proof requirements).

  • Open Banking and Open Finance APIs

    PSD2 in Europe, Open Banking UK, Open Finance Brazil (Resolução BCB 4.949), and the parallel initiatives in Mexico, Argentina, Australia, Canada — the regulatory-mandated API ecosystems that fintech companies, neobanks, and aggregators consume. The form captures the regulated-entity status of the requester (TPP under PSD2, Iniciador de Pagamentos under Brazil Open Finance, Account Information Service Provider under UK Open Banking), the certifications (eIDAS QWAC/QSeal for Europe, BCB authorization for Brazil), and the use case (account aggregation, payment initiation, identity verification, credit decisioning). The structured intake is what the platform team uses to validate regulatory-compliance posture before granting production API access.

Tailor it to your API platform

Every API platform has its own developer-relations conventions. Configure the integration-type options to match your platform's surface area — REST API, GraphQL, webhooks, OAuth (with scope picker), SDK in specific languages (Python, JavaScript/TypeScript, Go, Ruby, PHP, Java, C#, Swift, Kotlin), data export, bulk operations, real-time WebSocket streams, gRPC for high-volume internal scenarios. Configure the volume tiers to match your rate-limit-tier and pricing-tier definitions — under 10K/month is typically free tier; 10K-1M is starter; 1M-100M is growth; 100M+ is enterprise with custom rate limits. Configure the OAuth-scope picker to expose your scopes inline so developers can identify exactly what they need (and so security review can preempt the 'we need read-on-all-customers' scope sprawl that turns into a security incident). Configure the security-and-compliance-attestations field with what your platform requires — SOC 2 Type II for enterprise integrations, ISO 27001 for some EU customers, LGPD certified for Brazilian customers, ENS (Esquema Nacional de Seguridad) for Spanish public sector, HIPAA BAA for healthcare scopes, PCI-DSS attestation for payment scopes. Configure the listing-path field with your platform's marketplace structure — public listing (full marketplace approval review), partner-only (internal partner program review), embedded integration (customer-specific, no listing), internal use (development team only). Integrate with your developer-relations stack — ReadMe for docs hosting, Mintlify or Apidog for modern API docs, Postman for collection sharing, Stoplight for API design, Speakeasy or Stainless for SDK generation, ReadMe Dev Dash or Moesif or Treblle for API analytics, Discord or Slack Community or Common Room for developer community. For platforms running marketplace approvals through dedicated processes (Salesforce AppExchange, HubSpot Marketplace), integrate the form's submission with the marketplace-application workflow. For platforms with regulated-customer programs (HIPAA for healthcare APIs, PCI-DSS for payment APIs, LGPD or GDPR for sensitive-data APIs), the form's compliance section captures the upstream attestations the developer brings.

API integration request FAQs

The generic 'contact developer relations' link receives a mix of (1) questions the docs already answer (40-60 % of inbound, which is the docs team's failure but is still DevRel's daily work), (2) legitimate API integration requests with custom needs (20-30 %), (3) developers asking for pricing or commercial terms (10-15 %), and (4) sales pitches misrouted as integration requests (5-10 %). DevRel teams that use this form report a 5-10x reduction in DevRel time spent on 'is your docs page X actually current?' questions because the form's integration-type and use-case fields route those questions to documentation feedback channels instead of DevRel. The structured intake also surfaces the volume and security signals at submission, so the DevRel team arrives at the technical discovery call already knowing whether this is a 100-request-per-month free-tier integration or a 100M-request-per-month enterprise candidate.
Expected request volume is the single most predictive signal for which API tier and support level a developer needs. Under 10K requests per month sits comfortably in most platforms' free or hobbyist tier with default rate limits, no SLA, community support; 10K-1M is typically the starter/builder paid tier with elevated rate limits, basic SLA, email support; 1M-100M is growth/business tier with custom rate limits, 99.9 % SLA, dedicated support; 100M+ is enterprise with negotiated rate limits, custom SLA (99.99 %+), dedicated CSM, and possibly dedicated infrastructure or regional deployment. The form's volume field auto-segments the developer into the right tier conversation, and the volume claim is also a leading indicator for whether the security and compliance review needs to escalate (because the higher-volume customers tend to have stricter data-residency and certification requirements that take 2-6 weeks of review before production access is granted).
OAuth scope sprawl is the #1 security incident pattern in API platforms — developers request more scope than they need (often because they did not read what each scope unlocks), platforms grant the scope because the request seemed reasonable at the time, and then a breach in the developer's infrastructure leaks data from the broader scope. The form's OAuth-scope picker shows each scope with the specific data it unlocks (read:customer.email vs. read:customer.* vs. read:all_customers — three orders of magnitude difference in blast radius), the rationale field forces the developer to justify each scope they pick, and the workflow auto-routes scopes above a sensitivity threshold to security review. The OAuth 2.0 / OIDC consent screen displayed to end users should also show the scopes in plain language — many platforms (including yours, if you have not audited recently) use jargon that end users do not understand, which is the basis for FTC enforcement actions in the US and AEPD/ANPD actions in EU/Brazil. The form's submission becomes the security-review record that informs the consent-screen approval.
On submission, the workflow can create the technical discovery record in your DevRel tools. For ReadMe (the most common platform-team docs solution), the developer gets auto-invited to your developer-portal with the right project scoping. For Mintlify or Apidog (modern docs platforms), similar onboarding. For Postman, the developer gets the workspace invite with the relevant collection shared, which dramatically reduces 'I cannot get curl to work' debugging. For Stoplight (API design and docs), the integration spec gets shared. For Speakeasy or Stainless (SDK generation), the SDK is auto-provisioned for the developer's chosen languages. For Discord or Slack Community (developer community), the developer gets the invite with the appropriate channel access. For Common Room or Orbit (community intelligence), the developer's activity is tracked for the DevRel team's relationship management. For internal Jira or Linear (platform team work tracking), the request creates the appropriate ticket for the platform team. For API analytics (ReadMe Dev Dash, Moesif, Treblle, Apitally), the developer's API usage is tracked from day-one with the use-case context attached.
Enterprise API integrations typically require an upstream security review before production access — the customer wants to confirm the platform meets their security and compliance bar (SOC 2 Type II, ISO 27001, HIPAA BAA, GDPR Art. 28 DPA, LGPD Contrato de Operador, PCI-DSS attestation, ENS for Spanish public sector, BCB authorization for Brazilian financial sector). The form's compliance-attestations field captures what the developer brings — the certifications they hold, the legal-entity structure of their organization, the data-residency requirements they have. The platform team then reciprocates with the appropriate attestation package (your SOC 2 report, your ISO 27001 certificate, your DPA template, your sub-processor list, your security questionnaire response). For high-trust integrations (payment processing, healthcare data, financial accounts, identity verification), the security review can take 4-12 weeks and is typically coordinated through a TPRM (Third-Party Risk Management) platform like OneTrust Vendorpedia, Whistic, SecurityScorecard, Black Kite, ProcessUnity, or Archer GRC. The form's structured intake produces the initial scoping document the security review starts from.

Related templates

Free Product-Market Fit Survey Template

The classic Sean Ellis PMF survey: "how would you feel if you couldn't use this product?" Plus the ICP, benefit, and roadmap questions that follow.

View template

Feature request form — capture problems, not just solutions

Feature request form template with problem-not-feature framing, current-workaround capture, and direct integration with Canny, Featurebase, Productboard

View template

User onboarding survey — personalize activation and segment new signups

Online user onboarding survey template for SaaS, consumer apps, developer tools, and marketplaces.

View template

Ready to build forms that work for you?

Create your first form in minutes. Your submissions will thank you.

Be first in lineLimited early accessSet up in 2 minutes