DEV Community: Preecha

Google API Gateway: Complete Guide, Features, & Best Practices

Preecha — Fri, 17 Jul 2026 01:01:36 +0000

APIs are central to modern application architecture, but securing, managing, and scaling them can become complex quickly. Google API Gateway provides a managed entry point for exposing backend services, applying policies, and monitoring API traffic on Google Cloud.

Try Apidog today

What Is Google API Gateway?

Google API Gateway is a fully managed Google Cloud service for creating, securing, and monitoring APIs that route requests to backend services. You can expose RESTful endpoints, apply authentication and access controls, manage traffic, and observe API activity from a centralized platform.

It can sit in front of services running on:

Cloud Functions
Cloud Run
App Engine
Compute Engine
Any HTTP(S) backend

A typical use case is exposing one stable public API URL while keeping backend services private and independently deployable.

Why Use Google API Gateway?

Without a gateway, every backend service may need to implement authentication, request validation, traffic controls, logging, and client-facing routing independently.

Google API Gateway helps centralize those concerns:

Centralized API management: Manage API definitions and gateway deployments from one place.
Security enforcement: Apply API keys, JWT validation, and IAM-based access controls without changing backend application code.
Traffic protection: Use quotas and rate limits to reduce the risk of backend overload.
Monitoring: Track request volume, latency, and errors through Google Cloud observability tools.
Managed scaling: Use Google Cloud infrastructure instead of operating gateway servers yourself.

Core Features

Integrated security

Google API Gateway supports common API security mechanisms, including:

Google Cloud IAM
API keys
JWT tokens

Configure requirements in your OpenAPI definition so that security rules are versioned alongside the API contract.

OpenAPI-based configuration

API Gateway uses OpenAPI specifications to define:

Routes and HTTP methods
Request parameters
Response definitions
Authentication requirements
Backend routing

Each API configuration is based on a version of your OpenAPI spec. Updating the specification requires creating and deploying a new API config.

Traffic management

Use gateway-level controls to help protect backend services from unexpected or abusive traffic:

Quotas
Rate limits
Consumer-level access policies

Monitoring and logging

Integrate with Google Cloud monitoring and logging tools to inspect:

Request counts
Error rates
Response latency
Endpoint-level traffic patterns

GCP backend integration

Google API Gateway can route requests to services such as Cloud Functions, Cloud Run, App Engine, Compute Engine, and other HTTP(S) backends.

Custom domains

You can expose APIs through custom domains and use managed SSL certificates.

Architecture Overview

A Google API Gateway implementation generally has three parts:

API config

An OpenAPI file defining routes, methods, security, schemas, and backend integrations.
Gateway resource

The public gateway endpoint that receives requests, applies configured policies, and routes traffic.
Backend services

The application logic that handles requests, such as Cloud Run services or Cloud Functions.

The request flow looks like this:

Client
  ↓
Google API Gateway
  ↓ authentication, authorization, policies
Backend service
  ↓
Google API Gateway
  ↓
Client response

Set Up Google API Gateway

The following workflow deploys an OpenAPI-defined API through Google API Gateway.

Step 1: Prepare a backend service

Start with a backend that can receive HTTP(S) requests. This might be a Cloud Function, Cloud Run service, App Engine application, or another reachable HTTP backend.

For example, a simple Node.js Cloud Function:

exports.helloWorld = (req, res) => {
  res.send('Hello from Google API Gateway!');
};

Deploy it:

gcloud functions deploy helloWorld \
  --runtime nodejs18 \
  --trigger-http \
  --allow-unauthenticated

For production APIs, configure authentication according to your security requirements rather than exposing backend services unnecessarily.

Step 2: Define the OpenAPI specification

Create an openapi.yaml file that defines your API contract.

openapi: 3.0.0
info:
  title: Sample API
  version: 1.0.0

paths:
  /hello:
    get:
      responses:
        '200':
          description: Successful response

To route the endpoint to a backend, add x-google-backend:

openapi: 3.0.0
info:
  title: Hello API
  version: 1.0.0

paths:
  /hello:
    get:
      x-google-backend:
        address: https://REGION-PROJECT_ID.cloudfunctions.net/helloWorld
      responses:
        '200':
          description: A successful response

Replace REGION and PROJECT_ID with the values for your deployment.

Step 3: Create an API config

Create an API config from the OpenAPI file:

gcloud api-gateway api-configs create my-config \
  --api=my-api \
  --openapi-spec=openapi.yaml \
  --project=my-gcp-project \
  --backend-auth-service-account=my-service-account

Use a new config name whenever you update the OpenAPI definition. This gives you a versioned deployment history and makes rollouts more repeatable.

Step 4: Deploy the gateway

Create a gateway resource using the API config:

gcloud api-gateway gateways create my-gateway \
  --api=my-api \
  --api-config=my-config \
  --location=us-central1 \
  --project=my-gcp-project

After deployment, retrieve the gateway hostname and test the route:

curl https://GATEWAY_HOSTNAME/hello

Step 5: Add security requirements

Configure authentication and authorization in the OpenAPI spec or gateway settings. Common options include:

API keys for identifying consumers
JWT tokens for token-based authentication
IAM for Google Cloud identity-based access control

Keep security configuration in source control with the OpenAPI document so reviews cover both API behavior and access rules.

Step 6: Monitor the deployment

Use Google Cloud Console and Cloud Monitoring to review:

Request volume
Error responses
Endpoint latency
Logs from gateway and backend services

Set alerts for sustained error rates or latency increases so you can detect backend issues before they affect more users.

Best Practices

Version your API contract

Include API versions in your route structure or maintain separate OpenAPI versions.

/v1/orders
/v2/orders

Versioning lets existing clients continue using stable behavior while you introduce breaking changes in a newer version.

Automate deployments

Add API config creation and gateway deployment to CI/CD pipelines. A typical pipeline can:

Validate the OpenAPI file.
Run API tests.
Create a new API config.
Deploy or update the gateway.
Run smoke tests against the gateway URL.

Require authentication

Do not rely on backend code alone for API protection. Define authentication requirements at the gateway level and use HTTPS endpoints.

Set quotas and rate limits

Protect downstream services from sudden spikes, unintentional retry loops, and abusive clients. Choose limits based on backend capacity and expected consumer behavior.

Monitor continuously

Review logs, latency, and error metrics after every rollout. Monitoring is especially important when a gateway fronts multiple microservices because one backend issue can affect a shared API surface.

Real-World Use Cases

Microservices API aggregation

An e-commerce platform can place inventory, payments, and user-management services behind a unified API endpoint. The gateway centralizes routing and access control while clients interact with a simpler API surface.

Mobile application backend

A mobile application can expose backend endpoints to iOS and Android clients through the gateway, using authentication and rate limiting to reduce unauthorized or excessive traffic.

Third-party integrations

A SaaS provider can publish partner APIs behind Google API Gateway, enforce API keys, and apply quotas per consumer.

IoT device management

A smart-device platform can route device telemetry and command requests through the gateway to create a controlled, scalable entry point for backend services.

Practical Example: Serverless API Deployment

This example combines a Cloud Function with an OpenAPI definition and Google API Gateway.

1. Create the function

exports.helloWorld = (req, res) => {
  res.send('Hello from Google API Gateway!');
};

2. Deploy the function

gcloud functions deploy helloWorld \
  --runtime nodejs18 \
  --trigger-http \
  --allow-unauthenticated

3. Create `openapi.yaml`

openapi: 3.0.0
info:
  title: Hello API
  version: 1.0.0

paths:
  /hello:
    get:
      x-google-backend:
        address: https://REGION-PROJECT_ID.cloudfunctions.net/helloWorld
      responses:
        '200':
          description: A successful response

4. Create the API config and gateway

gcloud api-gateway api-configs create hello-config \
  --api=hello-api \
  --openapi-spec=openapi.yaml \
  --project=my-gcp-project \
  --backend-auth-service-account=my-service-account

gcloud api-gateway gateways create hello-gateway \
  --api=hello-api \
  --api-config=hello-config \
  --location=us-central1 \
  --project=my-gcp-project

5. Test the gateway endpoint

Once the gateway is available, call:

curl https://GATEWAY_HOSTNAME/hello

You should receive:

Hello from Google API Gateway!

Google API Gateway Pricing

Google API Gateway pricing is based on the number of calls and data processed. As of 2026, the pricing tiers are:

First 2 million calls per month: Free
Next 1 billion calls: $3 per million calls
Data processing: Additional data transfer charges may apply

Always check the official Google Cloud pricing page before estimating production costs.

Integrating Apidog with Google API Gateway

When building APIs for Google API Gateway, Apidog can support the API design and validation workflow.

Design and document APIs

Create REST API definitions visually and export OpenAPI specifications for use with Google API Gateway.

Mock and test endpoints

Before deploying a gateway config, mock endpoints and validate request and response formats. This helps catch contract issues before backend and gateway deployment.

Collaborate on API contracts

Use a shared API design workflow so developers, testers, and consumers can review the OpenAPI contract before it becomes a deployed gateway configuration.

A practical workflow is:

Design the API contract in Apidog.
Test request and response examples.
Export the OpenAPI specification.
Create a Google API Gateway config from the exported file.
Deploy the gateway through CI/CD.

Google API Gateway vs. Other API Management Solutions

Google API Gateway is designed for GCP-native workloads and provides:

Tight integration with Cloud Functions, Cloud Run, and App Engine
Managed IAM and API key support
No gateway server management
Usage-based pricing

If your requirements include advanced monetization, developer portals, or hybrid and multi-cloud API management, compare Google API Gateway with Google Apigee and other API management platforms.

For many GCP workloads, Google API Gateway provides a balance of managed operations, security controls, and straightforward deployment.

Frequently Asked Questions

Is Google API Gateway only for REST APIs?

Yes. Google API Gateway is optimized for RESTful APIs. For gRPC or WebSocket APIs, consider other GCP solutions.

Can I use custom domains with Google API Gateway?

Yes. You can map custom domains to API Gateway endpoints and manage SSL certificates from the Google Cloud console.

How do I secure APIs with Google API Gateway?

Configure authentication and authorization through OAuth, JWTs, API keys, or IAM-based controls. These policies can be applied at the gateway level without modifying backend code.

Can I monitor API usage in real time?

Yes. Google API Gateway integrates with Cloud Monitoring and Logging for metrics, logs, and alerts.

Next Steps

Google API Gateway provides a managed way to expose, secure, route, and monitor APIs on Google Cloud. Start with a small OpenAPI definition, deploy it behind a gateway, and add authentication, quotas, and monitoring before expanding the API surface.

Use an API design workflow to validate OpenAPI contracts before deployment, then automate config creation and gateway rollout through CI/CD for repeatable production releases.

How to Manage Internal vs External API: Complete Guide

Preecha — Thu, 16 Jul 2026 13:01:24 +0000

APIs are the backbone of modern digital ecosystems, powering internal workflows and customer-facing products. Managing internal and external APIs differently is essential for efficiency, security, scalability, and a reliable developer experience.

Try Apidog today

What Does Managing Internal vs External APIs Mean?

Internal APIs are used within your organization. External APIs are exposed to partners, customers, or the public.

Because their consumers, risk profiles, and stability requirements differ, they need different approaches to:

Governance and access control
Documentation and onboarding
Authentication and security
Monitoring and rate limiting
Versioning and deprecation
Testing, mocking, and sandboxing

The goal is the same for both: ship APIs that are secure, discoverable, and reliable without creating undocumented endpoints, breaking integrations, or exposing sensitive data.

Internal vs External API Management

Internal APIs: Private and Fast-Moving

Internal APIs connect services, automate workflows, and expose data between teams. They typically optimize for developer velocity and operational agility.

Common risks include:

Undocumented endpoints
Inconsistent authentication between services
API sprawl
Breaking changes that affect other teams
Accidental exposure of internal services

Focus on:

Team- and service-level access controls
Fast feedback loops for API changes
Private, version-controlled documentation
Simple onboarding for internal consumers
Observability across service-to-service calls

External APIs: Public or Partner-Facing

External APIs are consumed by third parties. They are part of your product surface, so reliability, documentation, and backward compatibility matter more.

Focus on:

Strong authentication and authorization
Public documentation and onboarding flows
Stable versions and clear deprecation policies
Rate limits and abuse detection
Per-consumer usage analytics
Sandbox environments for safe integration testing

How to Manage Internal vs External APIs

1. Define API Ownership and Governance

Every API should have an owner, a specification, and a lifecycle policy.

For internal APIs, define which team owns each service and who can make breaking changes. For external APIs, add formal review requirements before changing authentication, response formats, or versioned endpoints.

A practical ownership checklist:

Assign a team owner for every API.
Store the API specification with the service code or in a shared API workspace.
Define consumers and access requirements.
Document supported versions.
Record deprecation dates for older versions.
Review API changes before release.

For example, use clear naming conventions to distinguish internal and public routes:

/internal/v1/employees
/public/v1/orders
/partner/v1/orders

Route names alone do not provide security, but they make intent visible during reviews and operational monitoring.

2. Apply Different Access Controls

Internal APIs should still require authentication. Do not rely only on network location or the assumption that an endpoint is private.

For internal APIs:

Use role-based access control (RBAC).
Authenticate users and services through your identity provider.
Restrict network exposure where appropriate.
Use service-to-service authentication.
Segment sensitive services from general internal traffic.

For external APIs:

Use API keys or OAuth-based authentication where appropriate.
Enforce authorization scopes and tenant boundaries.
Apply rate limits per consumer.
Consider IP allowlists for trusted partner integrations.
Audit access logs regularly.

A simple rate-limit policy might differentiate public consumers from trusted partners:

Public API: 100 requests/minute per API key
Partner API: 1,000 requests/minute per API key
Internal service API: limit based on service capacity and expected traffic

The exact values depend on your infrastructure and expected usage, but the important part is defining and monitoring the policy.

3. Treat Documentation as Part of the API Contract

Documentation requirements differ by audience.

For internal APIs, keep docs concise and easy to update. Internal developers need endpoint details, authentication requirements, request examples, error responses, and ownership information.

For external APIs, documentation should also include:

Getting-started instructions
Authentication setup
Rate-limit behavior
Versioning policy
Error handling guidance
Changelog and migration guides
SDK or integration examples when available

For example, document a request and error response together:

POST /v1/orders
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "customer_id": "cus_123",
  "items": [
    {
      "sku": "sku_456",
      "quantity": 2
    }
  ]
}

{
  "error": {
    "code": "invalid_request",
    "message": "customer_id is required"
  }
}

Tools such as Apidog can help teams maintain version-controlled, interactive documentation for both private and public API consumers.

4. Secure Both API Types

Internal does not mean low-risk. Internal APIs can expose employee data, billing records, operational controls, or service credentials.

For internal APIs:

Require service-to-service authentication.
Validate all input.
Scan dependencies and services for vulnerabilities.
Use network segmentation for sensitive systems.
Avoid passing secrets through URLs or logs.

For external APIs:

Require TLS.
Use strong authentication and authorization.
Validate request payloads and query parameters.
Return consistent, non-sensitive error messages.
Monitor for abuse, credential stuffing, and unusual request patterns.
Apply rate limits and request size limits.

Avoid exposing implementation details in error responses:

{
  "error": {
    "code": "internal_error",
    "message": "An unexpected error occurred"
  }
}

Do not return stack traces, database queries, or internal service names to external consumers.

5. Monitor the Metrics That Matter

Internal and external APIs need different operational views.

For internal APIs, monitor:

Latency between services
Error rates
Dependency failures
Request volume by service
Resource usage
Bottlenecks in critical workflows

For external APIs, also monitor:

Usage by API key, partner, or tenant
Rate-limit violations
Authentication failures
Endpoint adoption
Unusual traffic patterns
Client errors caused by integration issues

Start with a small set of actionable metrics:

Request count
p95 latency
5xx error rate
4xx error rate
Authentication failures
Rate-limit rejections

Set alerts for conditions your team can act on, such as a sustained increase in 5xx responses or a sudden spike in failed authentication requests.

Apidog facilitates request logging and monitoring within its API development suite, helping teams review behavior during development and testing.

6. Use Versioning and Lifecycle Policies

Internal APIs can evolve more quickly, but consumers still need advance notice of breaking changes.

External APIs require stricter compatibility guarantees. A breaking change can disrupt partner or customer integrations, so define a versioning policy before publishing endpoints.

A common URL-based versioning pattern is:

/v1/orders
/v2/orders

Use a lifecycle process:

Publish the current API version and its contract.
Announce a replacement version when a breaking change is needed.
Provide migration guidance.
Run old and new versions in parallel during a defined transition period.
Track remaining consumers of the old version.
Deprecate and retire the old version according to the published policy.

For internal APIs, automated changelogs and consumer notifications can reduce the risk of surprise breakages. For external APIs, publish migration instructions and avoid removing fields or changing semantics without a version change.

7. Test With Mocks and Sandboxes

Mocks help teams begin integration before a backend implementation is complete.

For internal APIs:

Create mock responses from the API specification.
Let frontend and dependent-service teams test early.
Add contract tests to catch mismatches between the implementation and the spec.

For external APIs:

Provide a sandbox environment.
Use test credentials and test data.
Ensure sandbox behavior is documented.
Keep production credentials and data separate from test workflows.

A mock response for an order endpoint might look like:

{
  "id": "ord_mock_001",
  "status": "processing",
  "created_at": "2025-01-01T12:00:00Z"
}

Apidog’s built-in mocking capabilities can support early development and testing for both internal and external APIs.

How Apidog Helps Manage Internal and External APIs

Apidog is a spec-driven API development platform that can help teams standardize API workflows across internal and external services.

Key capabilities include:

Unified workspace: Manage internal and external APIs in one workspace to reduce duplication and sprawl.
Online documentation: Generate interactive documentation for private or public consumers.
Import and export: Import Swagger, Postman, and other formats.
Mock server: Create mock endpoints for development and integration testing.
Version control: Track API changes and share updates with internal teams or external partners.

A practical setup is to separate API visibility and access by audience:

Project: Platform APIs
├── Internal Services
│   ├── Employee Service
│   ├── Billing Service
│   └── Notification Service
└── External APIs
    ├── Partner Orders API
    └── Customer Reporting API

This keeps standards unified while allowing documentation, authentication, and publishing workflows to match each audience.

Practical Examples

Example 1: Internal API for an HR Dashboard

A company builds an internal API that aggregates employee data for HR dashboards.

Implementation steps:

Restrict access to HR and IT roles.
Require internal authentication for every request.
Publish endpoint documentation only to the internal developer portal or workspace.
Monitor latency and error rates for dashboard-critical endpoints.
Use mocks so frontend teams can build screens before data aggregation is complete.
Communicate contract changes to dashboard consumers before deployment.

Example 2: External API for Order Processing

The same company exposes an API that lets partners create and track orders.

Implementation steps:

Use OAuth 2.0 or API keys for partner authentication.
Scope access so each partner can access only its own orders.
Publish public documentation with request examples and error handling details.
Apply rate limits to prevent abuse and protect capacity.
Offer a sandbox for integration testing.
Version breaking changes and publish migration guides.
Monitor traffic by partner to identify adoption, errors, and potential misuse.

Example 3: Hybrid API Strategy for a SaaS Platform

A SaaS provider operates a multi-tenant platform with both internal microservices and customer-facing APIs.

A practical model:

Internal APIs connect microservices and use private documentation, internal authentication, and service-level monitoring.
External APIs use public documentation, API keys or OAuth, rate limits, and sandbox environments.
Both API groups use the same API specification standards, naming conventions, testing process, and change-review workflow.
Both sets of APIs can be managed in a single Apidog project while keeping their visibility and access policies separate.

Conclusion

Managing internal and external APIs is not a single checklist. The right approach depends on the API audience, sensitivity of the data, stability requirements, and business purpose.

Key takeaways:

Manage internal APIs for speed, discoverability, and secure service-to-service communication.
Manage external APIs for stability, security, onboarding, and consumer trust.
Document every API as a contract, not as an afterthought.
Use versioning, monitoring, mocks, and lifecycle policies to prevent integration failures.
Standardize documentation, testing, and change management with a platform such as Apidog.

How to Use Hootsuite API ?

Preecha — Thu, 16 Jul 2026 01:02:23 +0000

TL;DR

Hootsuite’s public API was deprecated in 2024. To build social media management workflows today, integrate directly with native platform APIs—such as Facebook Graph API, X/Twitter API v2, LinkedIn Marketing API, Instagram Graph API, and YouTube Data API. This guide shows how to implement OAuth 2.0, publish and schedule multi-platform posts, aggregate analytics, manage team permissions, and handle rate limits.

Try Apidog today

Note: Hootsuite previously exposed a public API with OAuth 2.0 authentication and endpoints for profiles, posts, analytics, and teams. Since its deprecation, use Hootsuite partner integrations, webhooks, or native social platform APIs for similar functionality.

Introduction

Hootsuite manages over 30 million social media accounts for 200,000+ businesses across 175+ countries. If you are building a social media dashboard, marketing platform, or reporting tool, direct API integrations let you automate publishing, engagement monitoring, and analytics collection.

For teams managing 20+ accounts, the core implementation goal is usually the same:

Connect each social account with OAuth.
Store and refresh tokens securely.
Normalize post data into a shared internal format.
Publish through platform-specific adapters.
Queue scheduled posts and retries.
Aggregate platform metrics into a reporting model.

Hootsuite API Status and Alternatives

Current API Situation

As of 2024, Hootsuite has deprecated its public API. Consider one of these approaches instead:

Approach	Description	Best for
Native platform APIs	Direct integration with Facebook, X/Twitter, LinkedIn, and other platforms	Full control and custom workflows
Audiense	Hootsuite-owned audience intelligence	Audience analysis
HeyOrca	Social media scheduling API	Content calendars
Buffer API	Social media management	Small teams
Sprout Social API	Enterprise social management	Large organizations
Agorapulse API	Social media CRM	Community management

Recommended Approach: Native Platform APIs

For most custom applications, native APIs provide the most control over publishing, account management, and analytics.

Platform	API	Typical capabilities
Facebook and Instagram	Graph API	Posts, insights, comments
X/Twitter	API v2	Tweets, analytics, streams
LinkedIn	Marketing API	Posts, company pages, ads
Pinterest	API v5	Pins, boards, analytics
TikTok	Display API	Videos and user info
YouTube	Data API	Videos, playlists, analytics

Getting Started: Multi-Platform Authentication

Step 1: Register Developer Apps

Create a developer application for every platform you support. Store app credentials in environment variables rather than source control.

const SOCIAL_CREDENTIALS = {
  facebook: {
    appId: process.env.FB_APP_ID,
    appSecret: process.env.FB_APP_SECRET,
    redirectUri: process.env.FB_REDIRECT_URI
  },
  twitter: {
    apiKey: process.env.TWITTER_API_KEY,
    apiSecret: process.env.TWITTER_API_SECRET,
    redirectUri: process.env.TWITTER_REDIRECT_URI
  },
  linkedin: {
    clientId: process.env.LINKEDIN_CLIENT_ID,
    clientSecret: process.env.LINKEDIN_CLIENT_SECRET,
    redirectUri: process.env.LINKEDIN_REDIRECT_URI
  },
  instagram: {
    appId: process.env.FB_APP_ID, // Uses Facebook Login
    appSecret: process.env.FB_APP_SECRET
  }
};

Use separate redirect URIs where needed, for example:

https://your-app.example.com/oauth/facebook/callback
https://your-app.example.com/oauth/twitter/callback
https://your-app.example.com/oauth/linkedin/callback

Step 2: Generate OAuth 2.0 Authorization URLs

Create a shared authorization URL builder, but keep scopes and endpoints platform-specific.

const getAuthUrl = (platform, state) => {
  const configs = {
    facebook: {
      url: 'https://www.facebook.com/v18.0/dialog/oauth',
      params: {
        client_id: SOCIAL_CREDENTIALS.facebook.appId,
        redirect_uri: SOCIAL_CREDENTIALS.facebook.redirectUri,
        scope: [
          'pages_manage_posts',
          'pages_read_engagement',
          'instagram_basic',
          'instagram_content_publish'
        ].join(','),
        state
      }
    },
    twitter: {
      url: 'https://twitter.com/i/oauth2/authorize',
      params: {
        client_id: SOCIAL_CREDENTIALS.twitter.apiKey,
        redirect_uri: SOCIAL_CREDENTIALS.twitter.redirectUri,
        scope: 'tweet.read tweet.write users.read offline.access',
        state,
        response_type: 'code'
      }
    },
    linkedin: {
      url: 'https://www.linkedin.com/oauth/v2/authorization',
      params: {
        client_id: SOCIAL_CREDENTIALS.linkedin.clientId,
        redirect_uri: SOCIAL_CREDENTIALS.linkedin.redirectUri,
        scope: 'w_member_social r_basicprofile',
        state,
        response_type: 'code'
      }
    }
  };

  const config = configs[platform];

  if (!config) {
    throw new Error(`Unsupported platform: ${platform}`);
  }

  return `${config.url}?${new URLSearchParams(config.params)}`;
};

Generate and persist a state value before redirecting the user. Validate it in the callback to prevent authorization-request forgery.

Step 3: Exchange the Authorization Code for Tokens

After the platform redirects to your callback route, exchange the authorization code for an access token.

const handleOAuthCallback = async (platform, code) => {
  const tokenEndpoints = {
    facebook: 'https://graph.facebook.com/v18.0/oauth/access_token',
    twitter: 'https://api.twitter.com/2/oauth2/token',
    linkedin: 'https://www.linkedin.com/oauth/v2/accessToken'
  };

  const credentials = SOCIAL_CREDENTIALS[platform];

  const response = await fetch(tokenEndpoints[platform], {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: new URLSearchParams({
      client_id:
        credentials.apiKey ||
        credentials.appId ||
        credentials.clientId,
      client_secret:
        credentials.appSecret ||
        credentials.apiSecret ||
        credentials.clientSecret,
      redirect_uri: credentials.redirectUri,
      code,
      grant_type: 'authorization_code'
    })
  });

  if (!response.ok) {
    throw new Error(`Token exchange failed for ${platform}`);
  }

  return response.json();
};

Step 4: Store Tokens Securely

Store tokens per user and per connected social account. Encrypt access and refresh tokens at rest.

const SocialToken = {
  userId: 'user_123',
  platform: 'facebook',
  accessToken: 'encrypted_token_here',
  refreshToken: 'encrypted_refresh_token',
  tokenExpiry: Date.now() + 5183999, // 60 days
  scopes: ['pages_manage_posts', 'pages_read_engagement'],
  pageId: 'page_456', // Facebook or Instagram account mapping
  pageName: 'My Business Page'
};

At minimum, persist:

The application user ID
Platform name
Encrypted access token
Encrypted refresh token, when provided
Token expiration time
Granted scopes
Connected page, organization, or account IDs

Post Scheduling and Publishing

Define a Shared Post Payload

Use one internal payload for your UI and scheduler, then translate it to each platform’s API format.

const postData = {
  message: 'New article: Building a multi-platform social publisher',
  link: 'https://example.com/articles/social-publisher',
  photo: 'https://example.com/images/social-publisher.png',
  platforms: ['facebook', 'twitter', 'linkedin', 'instagram'],
  facebookPageId: 'page_456',
  linkedinAuthorUrn: 'urn:li:organization:123',
  igAccountId: '17841400000000000'
};

Create a Multi-Platform Publisher

Call each platform adapter only when the selected platform is present.

const createSocialPost = async (postData) => {
  const results = {};

  if (postData.platforms.includes('facebook')) {
    results.facebook = await postToFacebook({
      pageId: postData.facebookPageId,
      message: postData.message,
      link: postData.link,
      photo: postData.photo
    });
  }

  if (postData.platforms.includes('twitter')) {
    results.twitter = await postToTwitter({
      text: postData.message,
      media: postData.photo
    });
  }

  if (postData.platforms.includes('linkedin')) {
    results.linkedin = await postToLinkedIn({
      authorUrn: postData.linkedinAuthorUrn,
      text: postData.message,
      contentUrl: postData.link
    });
  }

  if (postData.platforms.includes('instagram')) {
    results.instagram = await postToInstagram({
      igAccountId: postData.igAccountId,
      imageUrl: postData.photo,
      caption: postData.message
    });
  }

  return results;
};

In production, record the result separately for every platform. A post may succeed on Facebook and fail on LinkedIn, so avoid treating multi-platform publishing as all-or-nothing.

Publish to a Facebook Page

const postToFacebook = async (postData) => {
  const token = await getFacebookPageToken(postData.pageId);

  const params = new URLSearchParams({
    message: postData.message,
    access_token: token
  });

  if (postData.link) {
    params.append('link', postData.link);
  }

  if (postData.photo) {
    params.append('photo', postData.photo);
  }

  const response = await fetch(
    `https://graph.facebook.com/v18.0/${postData.pageId}/feed?${params}`,
    { method: 'POST' }
  );

  return response.json();
};

Publish to X/Twitter

Upload media first when the post includes an image, then include the returned media ID in the tweet request.

const postToTwitter = async (postData) => {
  const token = await getTwitterToken();

  let mediaIds = [];

  if (postData.media) {
    const mediaUpload = await uploadTwitterMedia(postData.media, token);
    mediaIds = [mediaUpload.media_id_string];
  }

  const response = await fetch('https://api.twitter.com/2/tweets', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${token}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      text: postData.text,
      media: mediaIds.length > 0
        ? { media_ids: mediaIds }
        : undefined
    })
  });

  return response.json();
};

Publish to LinkedIn

const postToLinkedIn = async (postData) => {
  const token = await getLinkedInToken();

  const post = {
    author: postData.authorUrn,
    lifecycleState: 'PUBLISHED',
    specificContent: {
      'com.linkedin.ugc.ShareContent': {
        shareCommentary: {
          text: postData.text
        },
        shareMediaCategory: postData.contentUrl ? 'ARTICLE' : 'NONE',
        media: postData.contentUrl
          ? [{
              status: 'READY',
              media: postData.contentUrn,
              description: { text: postData.text }
            }]
          : []
      }
    },
    visibility: {
      'com.linkedin.ugc.MemberNetworkVisibility': 'PUBLIC'
    }
  };

  const response = await fetch('https://api.linkedin.com/v2/ugcPosts', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${token}`,
      'Content-Type': 'application/json',
      'X-Restli-Protocol-Version': '2.0.0'
    },
    body: JSON.stringify(post)
  });

  return response.json();
};

Publish to Instagram

Instagram publishing uses a two-step flow: create a media container, then publish it.

const postToInstagram = async (postData) => {
  const token = await getInstagramToken();

  const containerResponse = await fetch(
    `https://graph.facebook.com/v18.0/${postData.igAccountId}/media`,
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${token}`
      },
      body: JSON.stringify({
        image_url: postData.imageUrl,
        caption: postData.caption
      })
    }
  );

  const container = await containerResponse.json();

  const publishResponse = await fetch(
    `https://graph.facebook.com/v18.0/${postData.igAccountId}/media_publish`,
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${token}`
      },
      body: JSON.stringify({
        creation_id: container.id
      })
    }
  );

  return publishResponse.json();
};

Schedule Posts with a Job Queue

Do not rely on in-process timers for scheduled publishing. Save the post in your database and enqueue a delayed job.

const schedulePost = async (postData, scheduledTime) => {
  const scheduledPost = await db.scheduledPosts.create({
    message: postData.message,
    platforms: postData.platforms,
    scheduledTime,
    status: 'pending',
    media: postData.media,
    link: postData.link
  });

  await jobQueue.add(
    'publish-social-post',
    { postId: scheduledPost.id },
    { delay: scheduledTime - Date.now() }
  );

  return scheduledPost;
};

Process the queued job and persist the per-post result.

jobQueue.process('publish-social-post', async (job) => {
  const post = await db.scheduledPosts.findById(job.data.postId);

  try {
    const result = await createSocialPost(post);

    await db.scheduledPosts.update(post.id, {
      status: 'published',
      publishedAt: new Date(),
      results: result
    });

    return result;
  } catch (error) {
    await db.scheduledPosts.update(post.id, {
      status: 'failed',
      error: error.message
    });

    throw error;
  }
});

Track at least these states:

pending -> publishing -> published
                     -> failed

Analytics and Reporting

Fetch Cross-Platform Analytics

Each platform returns metrics in a different shape. Fetch the raw responses first, then normalize them into a shared reporting format.

const getSocialAnalytics = async (accountId, dateRange) => {
  const analytics = {
    facebook: await getFacebookAnalytics(accountId.facebook, dateRange),
    twitter: await getTwitterAnalytics(accountId.twitter, dateRange),
    linkedin: await getLinkedInAnalytics(accountId.linkedin, dateRange),
    instagram: await getInstagramAnalytics(accountId.instagram, dateRange)
  };

  const totals = {
    impressions: sum(analytics, 'impressions'),
    engagement: sum(analytics, 'engagement'),
    clicks: sum(analytics, 'clicks'),
    shares: sum(analytics, 'shares'),
    comments: sum(analytics, 'comments'),
    newFollowers: sum(analytics, 'newFollowers')
  };

  return { analytics, totals };
};

Fetch Facebook Insights

const getFacebookAnalytics = async (pageId, dateRange) => {
  const token = await getFacebookPageToken(pageId);

  const metrics = [
    'page_impressions_unique',
    'page_engaged_users',
    'page_post_engagements',
    'page_clicks',
    'page_fan_adds'
  ];

  const params = new URLSearchParams({
    metric: metrics.join(','),
    since: dateRange.from,
    until: dateRange.until,
    access_token: token
  });

  const response = await fetch(
    `https://graph.facebook.com/v18.0/${pageId}/insights?${params}`
  );

  return response.json();
};

Fetch X/Twitter Analytics

const getTwitterAnalytics = async (userId, dateRange) => {
  const token = await getTwitterToken();

  const response = await fetch(
    `https://api.twitter.com/2/users/${userId}/metrics/private`,
    {
      headers: {
        Authorization: `Bearer ${token}`
      }
    }
  );

  return response.json();
};

Fetch LinkedIn Analytics

const getLinkedInAnalytics = async (organizationId, dateRange) => {
  const token = await getLinkedInToken();

  const response = await fetch(
    `https://api.linkedin.com/v2/organizationalEntityFollowerStatistics?q=organizationalEntity&organizationalEntity=${organizationId}`,
    {
      headers: {
        Authorization: `Bearer ${token}`
      }
    }
  );

  return response.json();
};

Fetch Instagram Insights

const getInstagramAnalytics = async (igAccountId, dateRange) => {
  const token = await getInstagramToken();

  const metrics = [
    'impressions',
    'reach',
    'engagement',
    'profile_views',
    'follower_count'
  ];

  const params = new URLSearchParams({
    metric: metrics.join(','),
    period: 'day',
    since: dateRange.from,
    until: dateRange.until
  });

  const response = await fetch(
    `https://graph.facebook.com/v18.0/${igAccountId}/insights?${params}`,
    {
      headers: {
        Authorization: `Bearer ${token}`
      }
    }
  );

  return response.json();
};

Use a normalization layer before calculating totals, because raw API response structures differ across platforms.

function sum(analytics, metric) {
  return Object.values(analytics).reduce((total, platform) => {
    return total + (platform.data?.[metric] || 0);
  }, 0);
}

Team Management

Add Role-Based Access Control

A social publishing tool should restrict who can publish, approve, delete, or manage connected accounts.

const TEAM_ROLES = {
  ADMIN: 'admin',
  MANAGER: 'manager',
  CONTRIBUTOR: 'contributor',
  VIEWER: 'viewer'
};

const ROLE_PERMISSIONS = {
  [TEAM_ROLES.ADMIN]: [
    'create',
    'read',
    'update',
    'delete',
    'manage_team',
    'billing'
  ],
  [TEAM_ROLES.MANAGER]: [
    'create',
    'read',
    'update',
    'approve_posts'
  ],
  [TEAM_ROLES.CONTRIBUTOR]: [
    'create',
    'read'
  ],
  [TEAM_ROLES.VIEWER]: [
    'read'
  ]
};

const checkPermission = (userRole, requiredPermission) => {
  const permissions = ROLE_PERMISSIONS[userRole] || [];
  return permissions.includes(requiredPermission);
};

Check permissions before sensitive actions:

if (!checkPermission(currentUser.role, 'approve_posts')) {
  throw new Error('You do not have permission to approve posts.');
}

Rate Limiting

Platform Rate Limits

Rate limits differ by platform, endpoint, application type, and account plan. Use the applicable platform documentation as the source of truth.

Platform	Limit	Window
Facebook Graph	200 calls	Per hour per user
X/Twitter API v2	300 tweets	Per 15 minutes
LinkedIn	100–500 calls	Per day
Instagram	200 calls	Per hour

Implement Basic Rate Limit Handling

A central request wrapper prevents one platform adapter from exceeding its configured capacity.

class SocialMediaRateLimiter {
  constructor() {
    this.limits = {
      facebook: { limit: 200, window: 3600000 },
      twitter: { limit: 300, window: 900000 },
      linkedin: { limit: 500, window: 86400000 },
      instagram: { limit: 200, window: 3600000 }
    };

    this.counters = {};
  }

  async request(platform, endpoint, options) {
    await this.waitForCapacity(platform);

    const response = await fetch(endpoint, options);
    this.incrementCounter(platform);

    return response;
  }

  async waitForCapacity(platform) {
    const limit = this.limits[platform];
    const counter = this.counters[platform] || {
      count: 0,
      resetTime: Date.now()
    };

    if (Date.now() > counter.resetTime + limit.window) {
      counter.count = 0;
      counter.resetTime = Date.now();
    }

    if (counter.count >= limit.limit) {
      const waitTime = counter.resetTime + limit.window - Date.now();

      await new Promise((resolve) => setTimeout(resolve, waitTime));
    }

    this.counters[platform] = counter;
  }

  incrementCounter(platform) {
    if (!this.counters[platform]) {
      this.counters[platform] = {
        count: 0,
        resetTime: Date.now()
      };
    }

    this.counters[platform].count++;
  }
}

For production workloads, also capture rate-limit response headers when platforms provide them and log failed requests for retries.

Production Deployment Checklist

Before going live, verify that your integration includes:

[ ] OAuth 2.0 flows for every supported platform
[ ] Encrypted token storage
[ ] Automatic token refresh where supported
[ ] Rate limiting per platform
[ ] API error handling and retry logic
[ ] Logging for API requests and responses
[ ] Post approval workflows
[ ] Content moderation
[ ] Analytics aggregation
[ ] Backup publishing mechanisms
[ ] Per-platform publishing status records
[ ] Monitoring for failed scheduled jobs

Real-World Use Cases

Social Media Dashboard

A marketing agency needs to manage 50+ client accounts across multiple platforms.

Challenge: Switching between platform dashboards and manually publishing content.
Implementation: Build a central dashboard with connected accounts, a unified composer, scheduled jobs, and aggregated analytics.
Result: 60% time savings and more consistent brand presence.

Automated Content Distribution

A publisher wants each new article distributed across social channels automatically.

Challenge: Manually sharing every article after publishing.
Implementation: Trigger a job when an article is published, generate a shared post payload, then send it through platform-specific publishing adapters.
Result: Instant distribution and 3x social traffic.

Conclusion

Although Hootsuite’s public API is deprecated, native platform APIs still provide the building blocks for social media management products.

The implementation priorities are:

Implement OAuth 2.0 separately for each platform.
Store access tokens securely and handle refresh flows.
Use platform-specific publishing adapters behind a shared post model.
Queue scheduled posts instead of relying on application timers.
Respect platform-specific rate limits.
Normalize analytics before building cross-platform reports.
Apply role-based permissions to publishing and team-management actions.
Use Apidog to streamline API testing and team collaboration.

FAQ

Does Hootsuite still have an API?

Hootsuite deprecated its public API in 2024. Use native platform APIs or alternative management platforms such as Buffer, Sprout Social, or Agorapulse.

How do I post to multiple platforms at once?

Implement OAuth for each platform, create a shared post payload, and call a platform-specific publishing function for every selected network.

What are the rate limits for social media APIs?

Limits vary by platform. Examples include Facebook at 200 calls per hour, X/Twitter at 300 tweets per 15 minutes, LinkedIn at 100–500 calls per day, and Instagram at 200 calls per hour.

How do I schedule posts?

Store posts with a scheduledTime in your database, then use a job queue such as Bull or Agenda to publish them at the scheduled time.

Can I get analytics from all platforms?

Yes. Each platform provides analytics APIs. Fetch platform-specific metrics, normalize the responses, and aggregate the results for cross-platform reporting.

Top 10 Open Finance API Use Cases for Modern Fintech

Preecha — Wed, 15 Jul 2026 13:01:28 +0000

Open finance API use cases are transforming financial services by enabling secure, standardized, permissioned access to financial data and services. Developers can use these APIs to build products across banking, payments, investments, insurance, and pensions without requiring users to manually move data between providers.

Try Apidog today

This guide covers the most common open finance API use cases, the API flows behind them, and practical implementation examples. The goal is to help developers choose a use case, design the integration, and test it before production.

What Are Open Finance API Use Cases?

Open finance API use cases are practical implementations of APIs that let users share, access, or act on financial data with explicit consent.

Open banking commonly focuses on current accounts and payment initiation. Open finance extends that model to a wider set of products, including:

Bank accounts and payments
Investments and pensions
Loans and credit products
Insurance policies
Account ownership and identity data

For developers, this broader access enables products that combine data from multiple institutions into a single workflow.

Why They Matter

Open finance APIs can help teams:

Build products with broader data access for more complete financial insights.
Integrate across institutions through standardized interfaces.
Reduce time to market by building on existing financial infrastructure.
Create personalized experiences using consented customer data.
Automate manual financial workflows, such as income verification or payment reconciliation.

Key Open Finance API Use Cases

1. Personal Financial Management and Account Aggregation

Use case: Aggregate data from bank accounts, investment accounts, loans, and insurance products into a single financial dashboard.

A personal financial management (PFM) application typically retrieves:

Account balances
Transaction histories
Investment positions
Loan balances
Insurance policy details

Typical API flow

The user connects an institution and grants consent.
The app receives an access token or authorization grant.
The backend requests account, balance, and transaction data.
The application normalizes provider-specific responses.
The UI displays consolidated balances, spending categories, and budgets.

Example

Apps such as Yolt, Mint, and Emma aggregate data across accounts to help users monitor expenses, budgets, and savings.

2. Instant Payments and Money Movement

Use case: Initiate account-to-account payments in real time or near real time.

Instead of relying only on card networks, an application can use payment initiation APIs to request a transfer directly from a user’s bank account.

Typical API flow

The user enters an amount and selects a payee.
Your application creates a payment request.
The user authorizes the payment with their bank.
The bank processes the transfer.
Your application receives a status update or callback.

Example

Payment initiation services in Europe under PSD2 and UPI in India support account-to-account transfers through APIs. Fintechs such as Wise and Revolut use these capabilities for fast international payments.

3. Automated Lending and Credit Scoring

Use case: Automate loan applications and underwriting using consented transaction and income data.

Rather than requesting PDFs or manually reviewing bank statements, a lender can retrieve recent financial data through an API.

Data commonly used

Income deposits
Recurring expenses
Account balances
Existing debt payments
Transaction patterns

Typical API flow

The applicant consents to share financial data.
The lender retrieves account and income information.
An underwriting model evaluates the data.
The system returns an approval, rejection, or request for additional review.

Platforms such as Upstart and Kabbage use open finance APIs to automate parts of loan approval workflows.

4. Identity Verification and Compliance (KYC and AML)

Use case: Verify customer identity, account ownership, and financial activity during onboarding or ongoing compliance checks.

API integrations can help retrieve verified identity details, account ownership information, and transaction history directly from financial institutions.

Implementation checklist

Request only the data required for the verification workflow.
Store consent records and authorization timestamps.
Validate account-owner details against the onboarding profile.
Handle expired consent and token refresh flows.
Log API access for audit and troubleshooting purposes.

Platforms may integrate identity and account verification services such as Plaid Identity or Onfido to reduce onboarding friction and fraud risk.

5. Wealth Management and Investment Aggregation

Use case: Show users or advisors a consolidated view of investments held across brokerages, pension accounts, and asset classes.

API data to retrieve

Portfolio balances
Positions and holdings
Asset allocation
Transaction history
Account performance data

Typical implementation

Connect brokerage and pension accounts through consent-based authorization.
Fetch holdings and balances on a scheduled basis.
Normalize symbols, currencies, and asset classifications.
Calculate aggregate allocation and performance metrics.
Present the results in a portfolio dashboard.

Robo-advisors and wealthtech applications such as Nutmeg and Personal Capital use APIs to aggregate assets and support tailored advice.

6. Embedded Finance and Banking-as-a-Service

Use case: Embed payments, lending, insurance, or payout capabilities into a non-financial product.

Examples include:

A ride-sharing app offering instant driver payouts
An e-commerce platform offering point-of-sale financing
A gig platform supporting earned wage access
A marketplace collecting and distributing seller payments

API design considerations

Separate customer, account, payment, and payout resources.
Use idempotency keys for payment-creation requests.
Verify webhook signatures before processing events.
Track payment states, including pending, completed, failed, and reversed.
Design clear error responses for failed authorization or insufficient funds.

Open finance APIs make it possible to connect these financial capabilities to apps and platforms through compliant integrations.

7. Account Verification and Fraud Prevention

Use case: Confirm account ownership and account validity before sending money.

This reduces failed payments and helps prevent fraud in workflows such as payroll, refunds, and merchant payouts.

Common verification checks

Does the account exist?
Does the account holder match the expected beneficiary?
Is the account eligible to receive payments?
Is there sufficient balance for a requested transaction?

Payroll platforms and payment processors can use account verification APIs before issuing payments to employees or customers.

8. Data Portability and Consent Management

Use case: Give users control over who can access their financial data and for how long.

A consent-management implementation should support:

Creating consent records
Showing connected institutions and authorized scopes
Displaying authorization expiry dates
Revoking access
Recording consent changes for compliance

These capabilities help organizations support regulations such as GDPR and Section 1033 while making financial data sharing more transparent for users.

9. Insurance Data Access and Aggregation

Use case: Aggregate life, auto, or health insurance policy data for a unified customer view.

Possible application features

Display all policies in one dashboard.
Track coverage and renewal dates.
Compare policy details.
Identify cross-selling opportunities.
Generate personalized insurance recommendations.

Open finance APIs can provide a standardized way to retrieve, update, and analyze policy data across insurers.

10. Business Financial Management and Cash Flow Insights

Use case: Give businesses a current view of cash flow, invoices, payables, and liquidity across accounts and accounting systems.

Data sources to combine

Bank account balances
Transaction feeds
Outstanding invoices
Accounts payable
Accounting platform data

Business finance platforms such as QuickBooks, Xero, and Agicap use APIs to aggregate and analyze company financial data.

Practical Open Finance API Examples

The following examples show simplified implementation flows. Actual endpoint paths, authorization requirements, and response schemas vary by provider.

Example 1: Aggregate Account Balances

Scenario: A user wants to view bank and investment balances in one dashboard.

API flow

The user grants consent to the PFM app.
The app receives access credentials for each connected provider.
The backend requests balances from banks and brokers.
The backend returns a normalized response to the frontend.

import requests

def get_balances(api_endpoints, access_tokens):
    results = {}

    for name, endpoint in api_endpoints.items():
        response = requests.get(
            endpoint,
            headers={
                "Authorization": f"Bearer {access_tokens[name]}"
            },
            timeout=10
        )
        response.raise_for_status()

        results[name] = response.json()["balance"]

    return results

api_endpoints = {
    "BankA": "https://api.banka.com/v1/accounts/balance",
    "BrokerB": "https://api.brokerb.com/v1/portfolio/balance"
}

access_tokens = {
    "BankA": "token_bank_a",
    "BrokerB": "token_broker_b"
}

print(get_balances(api_endpoints, access_tokens))

In production, avoid exposing provider tokens to the client. Store and use them from a secure backend service.

Example 2: Initiate an Instant Payment

Scenario: A fintech app lets users pay a utility bill directly from a bank account.

API flow

The user selects the payee and payment amount.
Your backend creates a payment initiation request.
The user authorizes the payment with their bank.
The bank processes the transfer.
Your system receives a callback or polls for the final payment status.

{
  "debtorAccount": {
    "iban": "DE89370400440532013000"
  },
  "creditorAccount": {
    "iban": "DE75512108001245126199"
  },
  "amount": {
    "currency": "EUR",
    "value": "150.00"
  },
  "remittanceInformation": "Utility Bill March"
}

For payment APIs, handle duplicate submission safely. A common approach is to send an idempotency key with the request and persist the resulting payment ID.

Example 3: Automate a Loan Decision

Scenario: A digital lender retrieves income data after a user grants consent, then evaluates the application automatically.

API flow

The user authorizes financial data sharing.
The lender fetches transaction and income data.
The underwriting service evaluates the data.
The system returns a decision.

const income = await api.get("/accounts/income", {
  headers: {
    Authorization: "Bearer user_token"
  }
});

const score = creditModel.evaluate(income.data);

if (score > threshold) {
  approveLoan();
} else {
  rejectLoan();
}

In a real workflow, consider adding a manual-review path rather than treating every decision as an automatic approval or rejection.

How to Build and Test Open Finance APIs with Apidog

Developing open finance integrations requires a repeatable workflow for API design, testing, documentation, and change management.

Apidog can support this workflow with the following steps:

Design the API contract

Define endpoints for consent, account connections, balances, transactions, payment initiation, and webhooks. Document required scopes, request fields, response schemas, and error codes.
Mock provider responses

Create representative responses for successful authorization, expired consent, insufficient funds, invalid accounts, and unavailable provider services. This lets frontend and backend teams develop in parallel.
Import external API definitions

Import API specifications from formats such as Swagger or Postman, then validate requests and responses against the expected schema.
Test integration scenarios

Build test cases for the full workflow: authorization, data retrieval, payment initiation, webhook delivery, consent revocation, and token expiration.
Generate and maintain documentation

Keep endpoint documentation aligned with implementation changes so developers, product teams, and compliance stakeholders use the same contract.
Track API changes

Version changes to fields, endpoints, and authentication requirements to reduce integration breakage across teams.

Whether you are building a personal finance aggregator, payment platform, lending marketplace, or business cash-flow tool, a spec-driven API workflow helps make open finance integrations easier to test and maintain.

Conclusion

Open finance API use cases span consumer financial management, payments, lending, compliance, investment aggregation, insurance, and business finance.

To implement them effectively:

Start with a clear user-consent flow.
Define and document API contracts before building integrations.
Normalize data from multiple providers.
Test success, failure, and expiry scenarios.
Protect tokens and sensitive financial data.
Build for compliance, auditability, and user control.

The right use case depends on your product, but the implementation pattern remains consistent: obtain consent, securely access data or initiate an action, normalize provider responses, and provide a clear user experience.

How to Use iPay API for Payment Integration in 2026?

Preecha — Wed, 15 Jul 2026 01:02:05 +0000

TL;DR

The iPay API enables developers to integrate payment processing, invoicing, and financial transactions programmatically. It uses OAuth 2.0 and API key authentication, RESTful endpoints for payments, refunds, transactions, and reconciliation, with PCI DSS compliance requirements and industry-standard rate limits. This guide covers authentication setup, payment processing, webhook integration, security compliance, and production deployment strategies.

Try Apidog today

Introduction

Digital payment processing handles over $8 trillion annually worldwide. For developers building e-commerce platforms, SaaS applications, or marketplace solutions, payment API integration is essential for accepting customer payments securely and compliantly.

Businesses can lose 5–10% of revenue to failed payments, manual reconciliation, and payment fraud. A solid payment API integration automates payment processing, reduces failures with retry logic, enables automatic reconciliation, and supports fraud detection.

This guide walks through payment API integration end to end: authentication, payment processing, refunds, customer management, webhooks, PCI DSS requirements, and production deployment.

💡 Apidog simplifies payment API testing. Test payment endpoints in sandbox mode, validate webhook signatures, inspect transaction responses, and debug integration issues in one workspace. Import API specifications, mock responses, and share test scenarios with your team.

Note: This guide covers general payment API integration patterns applicable to iPay and similar payment processors. Specific endpoint URLs and authentication details may vary—always refer to official iPay documentation for implementation details.

What Is the iPay API?

Payment APIs like iPay provide RESTful interfaces for processing financial transactions. Typical capabilities include:

Payment authorization and capture
Refunds and chargebacks
Transaction history and reporting
Customer tokenization (vault)
Subscription and recurring billing
Invoice generation and management
Reconciliation and settlement
Fraud detection and prevention

Key Features

Feature	Description
RESTful API	JSON-based endpoints
OAuth 2.0 + API Keys	Secure authentication
Webhooks	Real-time payment notifications
Tokenization	Secure card storage
3D Secure	SCA compliance
PCI DSS	Level 1 compliance required
Multi-Currency	100+ currencies supported
Fraud Tools	Risk scoring and velocity checks

Payment Flow Overview

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Customer  │───▶│   Merchant  │───▶│  Payment    │
│   (Browser) │    │   (Server)  │    │  Gateway    │
└─────────────┘    └─────────────┘    └─────────────┘
     │                    │                    │
     │  1. Enter Card     │                    │
     │───────────────────▶│                    │
     │                    │                    │
     │  2. Tokenize       │                    │
     │───────────────────▶│  3. Create Intent  │
     │                    │───────────────────▶│
     │                    │                    │
     │                    │  4. Confirm Payment│
     │                    │───────────────────▶│
     │                    │                    │
     │                    │  5. Result         │
     │                    │◀───────────────────│
     │                    │                    │
     │  6. Receipt        │                    │
     │◀───────────────────│                    │

Keep sensitive card data on the client. Your server should receive a token or payment method ID, then create or confirm the payment through the provider API.

API Environments

Environment	URL	Use Case
Sandbox	`https://sandbox.ipay.com/api`	Development and testing
Production	`https://api.ipay.com/api`	Live transactions

Getting Started: Authentication Setup

Step 1: Create an iPay Account

Before accessing the API:

Visit iPay merchant registration.
Complete business verification (KYB).
Submit the required documents:
- Business registration
- Bank account details
- Government ID
Wait for approval, which may take 1–3 business days.

Step 2: Generate API Credentials

In the iPay Merchant Dashboard:

Go to Settings > API Keys.
Create a new API key.
Copy the key and secret into your secret manager or local environment file.

# .env file — NEVER commit this file to git
IPAY_API_KEY="live_xxxxxxxxxxxxxxxxxxxx"
IPAY_API_SECRET="secret_xxxxxxxxxxxxxxxxxxxx"
IPAY_WEBHOOK_SECRET="whsec_xxxxxxxxxxxxxxxxxxxx"

Use separate credentials for sandbox and production.

Step 3: Choose an Authentication Method

Method	Best For	Security Level
Basic Auth	Server-to-server integrations	High
OAuth 2.0	Multi-tenant applications	Higher
JWT	Microservices	High

Step 4: Create a Reusable API Client

Centralize authentication, JSON headers, idempotency keys, and error handling in one function.

const IPAY_BASE_URL = process.env.IPAY_SANDBOX
  ? 'https://sandbox.ipay.com/api'
  : 'https://api.ipay.com/api';

const ipayRequest = async (endpoint, options = {}) => {
  const apiKey = process.env.IPAY_API_KEY;
  const apiSecret = process.env.IPAY_API_SECRET;

  // Basic authentication (Base64 encoded)
  const authHeader = Buffer.from(`${apiKey}:${apiSecret}`).toString('base64');

  const response = await fetch(`${IPAY_BASE_URL}${endpoint}`, {
    ...options,
    headers: {
      Authorization: `Basic ${authHeader}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': options.idempotencyKey || generateIdempotencyKey(),
      ...options.headers
    }
  });

  if (!response.ok) {
    const error = await response.json();
    throw new Error(`iPay API Error: ${error.message}`);
  }

  return response.json();
};

function generateIdempotencyKey() {
  return `req_${Date.now()}_${Math.random().toString(36).substr(2, 9)}`;
}

// Usage
const account = await ipayRequest('/account');
console.log(`Merchant: ${account.business_name}`);

Payment Processing

Create a Payment Intent

Create payments from your server, using amounts in the smallest currency unit. For USD, $29.99 becomes 2999.

const createPayment = async (paymentData) => {
  const payment = {
    amount: paymentData.amount,
    currency: paymentData.currency || 'USD',
    customer: paymentData.customerId,
    payment_method: paymentData.paymentMethodId,
    confirm: true,
    description: paymentData.description,
    metadata: {
      orderId: paymentData.orderId,
      customerId: paymentData.customerId
    },
    capture_method: paymentData.captureMethod || 'automatic',
    statement_descriptor: paymentData.statementDescriptor || 'MYCOMPANY'
  };

  return ipayRequest('/payments', {
    method: 'POST',
    body: JSON.stringify(payment),
    idempotencyKey: paymentData.idempotencyKey
  });
};

// Usage
const payment = await createPayment({
  amount: 2999, // $29.99
  currency: 'USD',
  customerId: 'cus_12345',
  paymentMethodId: 'pm_67890',
  description: 'Order #ORD-001',
  orderId: 'ORD-001',
  statementDescriptor: 'MYCOMPANY INC'
});

console.log(`Payment status: ${payment.status}`);
console.log(`Payment ID: ${payment.id}`);

Generate and persist one idempotency key per checkout attempt. Reuse it if your application retries the same payment request.

Payment Status Flow

requires_payment_method → requires_confirmation → requires_action
                         → processing → requires_capture → succeeded
                                                        → failed
                                                        → canceled

Your application should treat payment status as asynchronous. Do not mark an order as paid only because the initial API request returned successfully—use the resulting payment status and verified webhook events.

Payment Methods

Method	Type	Use Case
`card`	Credit/Debit	Standard payments
`bank_transfer`	ACH, SEPA	Low-fee transfers
`digital_wallet`	Apple Pay, Google Pay	Mobile checkout
`buy_now_pay_later`	Klarna, Afterpay	Installment payments

Tokenize Card Details

Do not send raw card details to your server. Tokenize payment details in the browser or mobile app, then send only the resulting token ID to your backend.

const tokenizeCard = async (cardData) => {
  // NEVER send raw card data to your server.
  // Use client-side tokenization instead.

  const response = await fetch(`${IPAY_BASE_URL}/tokens`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${CLIENT_PUBLISHABLE_KEY}`
    },
    body: JSON.stringify({
      card: {
        number: cardData.number,
        exp_month: cardData.expMonth,
        exp_year: cardData.expYear,
        cvc: cardData.cvc
      }
    })
  });

  const token = await response.json();
  return token; // Send token.id to your server
};

On the server, exchange the token for a payment method:

const createPaymentMethod = async (tokenId, customerId) => {
  return ipayRequest('/payment_methods', {
    method: 'POST',
    body: JSON.stringify({
      type: 'card',
      token: tokenId,
      customer: customerId
    })
  });
};

Handle 3D Secure Authentication

For Strong Customer Authentication (SCA), your server may need to return a client secret and let the client complete the challenge.

const createPaymentWith3DS = async (paymentData) => {
  const payment = await createPayment({
    ...paymentData,
    confirmation_token: true // Return client secret for 3DS
  });

  if (payment.status === 'requires_action') {
    return {
      requiresAction: true,
      clientSecret: payment.client_secret,
      nextAction: payment.next_action
    };
  }

  return { success: true, payment };
};

On the client, use iPay.js or the mobile SDK to present the authentication challenge when requiresAction is true.

Refund Management

Process a Full Refund

Use the original payment ID when creating a refund.

const refundPayment = async (paymentId, reason = null) => {
  const refund = {
    payment: paymentId,
    reason: reason || 'requested_by_customer'
  };

  return ipayRequest('/refunds', {
    method: 'POST',
    body: JSON.stringify(refund),
    idempotencyKey: `refund_${paymentId}_${Date.now()}`
  });
};

// Usage
const refund = await refundPayment('pay_12345', 'duplicate');
console.log(`Refund status: ${refund.status}`);
console.log(`Refund ID: ${refund.id}`);

Process a Partial Refund

Include an amount when refunding only part of a payment.

const partialRefund = async (paymentId, amount, reason = null) => {
  const refund = {
    payment: paymentId,
    amount, // Smallest currency unit
    reason: reason || 'requested_by_customer'
  };

  return ipayRequest('/refunds', {
    method: 'POST',
    body: JSON.stringify(refund),
    idempotencyKey: `refund_${paymentId}_${amount}_${Date.now()}`
  });
};

// Usage — refund $15.00 of a $29.99 payment
const refund = await partialRefund('pay_12345', 1500, 'partial_ship');
console.log(`Refunded: $${refund.amount / 100}`);

Refund Reasons

Reason Code	Description
`duplicate`	Duplicate charge
`fraudulent`	Fraudulent transaction
`requested_by_customer`	Customer request
`order_canceled`	Order cancellation
`product_not_received`	Item not delivered
`product_not_as_described`	Item differs from description

Customer Management

Create a Customer

Store customer records so you can support recurring payments and saved payment methods.

const createCustomer = async (customerData) => {
  const customer = {
    email: customerData.email,
    name: customerData.name,
    phone: customerData.phone,
    metadata: {
      internalId: customerData.internalId,
      tier: customerData.tier
    }
  };

  return ipayRequest('/customers', {
    method: 'POST',
    body: JSON.stringify(customer)
  });
};

// Usage
const customer = await createCustomer({
  email: 'customer@example.com',
  name: 'John Doe',
  phone: '+1-555-0123',
  internalId: 'USR-12345',
  tier: 'premium'
});

console.log(`Customer created: ${customer.id}`);

Attach a Payment Method

const attachPaymentMethod = async (paymentMethodId, customerId) => {
  return ipayRequest(`/payment_methods/${paymentMethodId}/attach`, {
    method: 'POST',
    body: JSON.stringify({
      customer: customerId
    })
  });
};

// Usage
await attachPaymentMethod('pm_67890', 'cus_12345');

List Saved Payment Methods

const getCustomerPaymentMethods = async (customerId) => {
  return ipayRequest(`/customers/${customerId}/payment_methods`);
};

// Usage
const methods = await getCustomerPaymentMethods('cus_12345');

methods.data.forEach((method) => {
  console.log(`${method.card.brand} ending in ${method.card.last4}`);
  console.log(`Expires: ${method.card.exp_month}/${method.card.exp_year}`);
});

Webhooks

Configure Webhooks

In the iPay Dashboard:

Go to Developers > Webhooks.
Click Add Endpoint.
Enter your HTTPS endpoint URL.
Select the events your integration needs.
Store the webhook signing secret in your environment configuration.

Webhook Events

Event	Trigger
`payment.succeeded`	Payment completed
`payment.failed`	Payment declined
`payment.refunded`	Refund processed
`payment.disputed`	Chargeback filed
`customer.created`	New customer
`customer.subscription.updated`	Subscription changed

Verify and Handle Webhooks

Use the raw request body for signature verification. Parsing JSON before verification can change the payload and invalidate the signature.

const express = require('express');
const crypto = require('crypto');
const app = express();

app.post(
  '/webhooks/ipay',
  express.raw({ type: 'application/json' }),
  async (req, res) => {
    const signature = req.headers['ipay-signature'];
    const payload = req.body;

    const isValid = verifyWebhookSignature(
      payload,
      signature,
      process.env.IPAY_WEBHOOK_SECRET
    );

    if (!isValid) {
      console.error('Invalid webhook signature');
      return res.status(401).send('Unauthorized');
    }

    const event = JSON.parse(payload.toString());

    switch (event.type) {
      case 'payment.succeeded':
        await handlePaymentSucceeded(event.data);
        break;
      case 'payment.failed':
        await handlePaymentFailed(event.data);
        break;
      case 'payment.refunded':
        await handlePaymentRefunded(event.data);
        break;
      case 'payment.disputed':
        await handlePaymentDisputed(event.data);
        break;
      default:
        console.log('Unhandled event type:', event.type);
    }

    return res.status(200).send('OK');
  }
);

function verifyWebhookSignature(payload, signature, secret) {
  const expectedSignature = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature, 'hex'),
    Buffer.from(expectedSignature, 'hex')
  );
}

Update your internal order state from webhook events:

async function handlePaymentSucceeded(data) {
  console.log(`Payment succeeded: ${data.id}`);

  await db.orders.update(data.metadata.orderId, {
    status: 'paid',
    paymentId: data.id,
    paidAt: new Date()
  });

  await sendOrderConfirmation(data.metadata.orderId);
}

async function handlePaymentFailed(data) {
  console.log(`Payment failed: ${data.id} - ${data.failure_code}`);

  await sendPaymentFailedEmail(data.customer, data.failure_message);

  await db.orders.update(data.metadata.orderId, {
    status: 'payment_failed',
    failureReason: data.failure_message
  });
}

Make webhook handlers idempotent as well. Payment providers can retry an event when your endpoint times out or returns a non-success response.

Security and Compliance

PCI DSS Requirements

Requirement	Implementation
Secure Network	Use HTTPS, firewalls, and secure configurations
Cardholder Data Protection	Never store CVV; encrypt PAN
Vulnerability Management	Apply regular security updates and anti-virus
Access Control	Use least privilege, MFA, and unique IDs
Monitoring	Enable logging and intrusion detection
Security Policy	Maintain documented policies and regular training

Security Practices to Implement

// 1. Use tokenization — NEVER handle raw card data
const token = await tokenizeCard(cardData); // Client-side

// 2. Add idempotency to every payment operation
const idempotencyKey = `pay_${orderId}_${Date.now()}`;

// 3. Validate amounts on the server
if (req.body.amount !== calculatedAmount) {
  throw new Error('Amount mismatch - possible tampering');
}

// 4. Log payment operations without sensitive data
logger.info('Payment attempted', {
  orderId,
  amount,
  currency,
  customerId,
  timestamp: new Date().toISOString()
  // NEVER log card numbers, CVV, or full payment method details
});

// 5. Load secrets from environment variables
const apiKey = process.env.IPAY_API_KEY;

// 6. Rate-limit payment endpoints
const paymentLimiter = rateLimit({
  windowMs: 60000,
  max: 10 // 10 payment attempts per minute
});

Production Deployment Checklist

Before processing live payments:

[ ] Complete the PCI DSS Self-Assessment Questionnaire.
[ ] Use HTTPS for all endpoints.
[ ] Store API keys in secure secret management.
[ ] Implement webhook signature verification.
[ ] Add idempotency for all payment operations.
[ ] Set up comprehensive logging without sensitive data.
[ ] Configure fraud detection rules.
[ ] Test refund and dispute flows.
[ ] Create a runbook for payment failures.
[ ] Set up monitoring and alerting.
[ ] Implement a backup payment processor.

Real-World Use Cases

E-commerce Checkout

An online retailer integrates payments:

Challenge: Manual payment processing and high abandonment.
Solution: One-page checkout with tokenized cards.
Result: 35% conversion increase and instant payments.

SaaS Subscription Billing

A software company automates billing:

Challenge: Manual invoice generation and collection.
Solution: Recurring payments with automatic retry.
Result: 95% on-time payment and 80% admin time savings.

Marketplace Escrow

A platform handles multi-party payments:

Challenge: Complex split payments between vendors.
Solution: Payment intents with transfer scheduling.
Result: Automated vendor payouts and reduced fraud.

Conclusion

Payment API integration requires careful attention to security, compliance, and error handling. The implementation priorities are:

Never handle raw card data—use tokenization.
Add idempotency to every payment operation.
Verify webhook signatures before processing events.
Comply with PCI DSS requirements.
Test payment, refund, dispute, and failure paths in sandbox before production.
Use Apidog to streamline API testing and team collaboration.

FAQ Section

How do I authenticate with iPay API?

Use Basic authentication with an API key and secret, or OAuth 2.0 for multi-tenant applications.

Can I store customer card details?

Yes, but you must be PCI DSS compliant. Use tokenization to store cards securely in iPay’s vault.

How do I handle failed payments?

Implement retry logic with exponential backoff, notify customers, and provide alternative payment methods.

What is idempotency and why is it important?

Idempotency ensures duplicate requests with the same key produce the same result, preventing duplicate charges.

How do I test payments without charging cards?

Use sandbox mode with test card numbers provided in iPay documentation.

What are webhook signatures?

They are cryptographic signatures that verify webhooks came from iPay rather than a malicious actor.

How to Use Instagram Graph API in 2026

Preecha — Tue, 14 Jul 2026 13:02:25 +0000

TL;DR

The Instagram Graph API lets you manage Instagram Business and Creator accounts programmatically. Use Facebook Login OAuth 2.0 for authentication, then publish content, retrieve insights, manage comments, and receive webhook events. Plan around the documented rate limit of 200 calls per hour per app.

Try Apidog today

Introduction

Instagram has over 2 billion monthly active users, and more than 200 million businesses use Instagram Business accounts. If you are building a social media scheduler, analytics dashboard, e-commerce workflow, or moderation tool, the Instagram Graph API provides the integration layer.

A production integration can automate publishing, comment moderation, sentiment workflows, and reporting across multiple accounts. This guide covers the implementation path:

Configure Facebook Login OAuth.
Retrieve the connected Instagram account ID.
Publish photos, videos, reels, and carousels.
Query media and account insights.
Manage comments.
Process real-time webhook events.
Handle rate limits and production concerns.

💡 Apidog can help test Instagram endpoints, validate OAuth flows, inspect API responses, mock responses, and share API test scenarios with your team.

What Is the Instagram Graph API?

Instagram Graph API provides programmatic access to Instagram Business and Creator accounts through the Facebook Graph API.

Use it for:

Publishing photos, videos, reels, and carousels
Retrieving media insights and account analytics
Managing comments and mentions
Direct messaging through Instagram Graph API and Messenger Platform
Tracking hashtags and mentions
Managing stories
Working with shopping and product tags

Key features

Feature	Description
Graph-based API	Node-based resource access
OAuth 2.0	Facebook Login authentication
Webhooks	Real-time notifications for comments and mentions
Rate limiting	200 calls per hour per app
Content publishing	Photos, videos, reels, and carousels
Insights	Engagement, reach, and impression metrics
Moderation	Comments, mentions, and message management

Account requirements

Account type	API access
Business Account	Full API access
Creator Account	Full API access
Personal Account	No API access; convert first
Private Account	Limited insights

API architecture

Instagram uses the Facebook Graph API URL structure:

https://graph.facebook.com/v18.0/

API versions

Version	Status	End date	Use case
v18.0	Current	March 2026	New integrations
v17.0	Deprecated	January 2026	Existing integrations
v16.0	Retired	Expired	Do not use

Facebook releases new versions quarterly. Target the latest stable version for new work.

Getting Started: Authentication Setup

Step 1: Create a Facebook app

Visit the Facebook Developers Portal.
Sign in with your Facebook account.
Create a Facebook App with the Business app type.
Add the Instagram Graph API product.

Step 2: Link an Instagram Business account

Connect the Instagram account to a Facebook Page:

Open Facebook Page Settings > Instagram.
Select Connect Account.
Log in to Instagram and authorize the connection.
Confirm that the Instagram Business or Creator account is linked.

Personal Instagram accounts cannot use the Graph API. Convert the account to Business or Creator in Instagram Settings before continuing.

Step 3: Start Facebook Login

Build an OAuth authorization URL with the permissions your app needs:

const FB_APP_ID = process.env.FB_APP_ID;
const FB_REDIRECT_URI = process.env.FB_REDIRECT_URI;

function getAuthUrl(state) {
  const params = new URLSearchParams({
    client_id: FB_APP_ID,
    redirect_uri: FB_REDIRECT_URI,
    scope: [
      'instagram_basic',
      'instagram_content_publish',
      'instagram_manage_comments',
      'instagram_manage_insights',
      'pages_read_engagement'
    ].join(','),
    state
  });

  return `https://www.facebook.com/v18.0/dialog/oauth?${params.toString()}`;
}

Redirect the user to getAuthUrl(state). After consent, Facebook redirects back to your FB_REDIRECT_URI with an authorization code that you exchange for an access token.

Required permissions

Permission	Description
`instagram_basic`	Basic profile information and media list
`instagram_content_publish`	Publish photos, videos, and carousels
`instagram_manage_comments`	Read and write comments
`instagram_manage_insights`	Access analytics data
`pages_read_engagement`	Page access for publishing
`pages_manage_posts`	Publish to the connected Page

Step 4: Exchange for a long-lived token

Short-lived tokens expire in one hour. Exchange them for long-lived tokens, which expire after 60 days.

const FB_APP_SECRET = process.env.FB_APP_SECRET;

async function exchangeForLongLivedToken(shortLivedToken) {
  const params = new URLSearchParams({
    grant_type: 'fb_exchange_token',
    client_id: FB_APP_ID,
    client_secret: FB_APP_SECRET,
    fb_exchange_token: shortLivedToken
  });

  const response = await fetch(
    `https://graph.facebook.com/v18.0/oauth/access_token?${params}`
  );

  if (!response.ok) {
    throw new Error(`Token exchange failed: ${await response.text()}`);
  }

  return response.json();
}

// Usage
const longLivedToken = await exchangeForLongLivedToken(shortLivedToken);
console.log(
  `Token expires: ${new Date(longLivedToken.expires_at * 1000)}`
);

Store the token encrypted and persist its expiration date so you can alert users before it expires.

Step 5: Retrieve the Instagram Business account ID

Fetch the Instagram account connected to a Facebook Page:

async function getInstagramAccountId(pageId, accessToken) {
  const params = new URLSearchParams({
    fields: 'instagram_business_account',
    access_token: accessToken
  });

  const response = await fetch(
    `https://graph.facebook.com/v18.0/${pageId}?${params}`
  );

  if (!response.ok) {
    throw new Error(`Failed to fetch Instagram account: ${await response.text()}`);
  }

  const data = await response.json();
  return data.instagram_business_account.id;
}

// Usage
const igAccountId = await getInstagramAccountId(
  '12345678',
  process.env.INSTAGRAM_ACCESS_TOKEN
);

console.log(`Instagram Account ID: ${igAccountId}`);

Step 6: Create a reusable API client

Use one helper for GET, POST, and DELETE requests. The Graph API accepts request parameters as URL-encoded form data for POST requests.

const IG_BASE_URL = 'https://graph.facebook.com/v18.0';

async function instagramRequest(endpoint, { method = 'GET', ...params } = {}) {
  const url = new URL(`${IG_BASE_URL}${endpoint}`);
  const accessToken = process.env.INSTAGRAM_ACCESS_TOKEN;

  if (method === 'GET') {
    url.searchParams.set('access_token', accessToken);

    for (const [key, value] of Object.entries(params)) {
      if (value !== undefined && value !== null) {
        url.searchParams.set(key, String(value));
      }
    }
  }

  const options = { method };

  if (method !== 'GET') {
    const body = new URLSearchParams({
      access_token: accessToken
    });

    for (const [key, value] of Object.entries(params)) {
      if (value !== undefined && value !== null) {
        body.set(key, String(value));
      }
    }

    options.body = body;
  }

  const response = await fetch(url, options);
  const data = await response.json();

  if (!response.ok) {
    throw new Error(
      `Instagram API Error: ${data.error?.message ?? 'Unknown error'}`
    );
  }

  return data;
}

// Usage
const account = await instagramRequest('/me');
console.log(`Instagram Account: ${account.username}`);

Content Publishing

Content publishing uses two steps:

Create a media container with /{ig-account-id}/media.
Publish that container with /{ig-account-id}/media_publish.

Publish a photo

async function publishPhoto(igAccountId, photoData) {
  const container = await instagramRequest(`/${igAccountId}/media`, {
    method: 'POST',
    image_url: photoData.imageUrl,
    caption: photoData.caption,
    location_id: photoData.locationId,
    is_carousel_item: 'false'
  });

  return instagramRequest(`/${igAccountId}/media_publish`, {
    method: 'POST',
    creation_id: container.id
  });
}

// Usage
const post = await publishPhoto('17841400000000000', {
  imageUrl: 'https://example.com/image.jpg',
  caption: 'Excited to announce our new product! 🚀 #launch #innovation',
  locationId: '123456789'
});

console.log(`Published media ID: ${post.id}`);

Publish a video or reel

Videos must finish processing before publishing. Poll the media container status before calling media_publish.

async function waitForVideoProcessing(creationId, maxAttempts = 30) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const status = await instagramRequest(`/${creationId}`, {
      fields: 'status_code'
    });

    if (status.status_code === 'FINISHED') {
      return;
    }

    if (status.status_code === 'EXPIRED') {
      throw new Error('Video processing expired');
    }

    await new Promise((resolve) => setTimeout(resolve, 2000));
  }

  throw new Error('Video processing timeout');
}

async function publishVideo(igAccountId, videoData) {
  const container = await instagramRequest(`/${igAccountId}/media`, {
    method: 'POST',
    video_url: videoData.videoUrl,
    cover_url: videoData.coverUrl,
    caption: videoData.caption,
    media_type: videoData.mediaType ?? 'REELS',
    share_to_feed: 'true'
  });

  await waitForVideoProcessing(container.id);

  return instagramRequest(`/${igAccountId}/media_publish`, {
    method: 'POST',
    creation_id: container.id
  });
}

// Usage
const reel = await publishVideo('17841400000000000', {
  videoUrl: 'https://example.com/video.mp4',
  coverUrl: 'https://example.com/cover.jpg',
  caption: 'A product demo in 30 seconds.',
  mediaType: 'REELS'
});

console.log(`Published reel ID: ${reel.id}`);

Publish a carousel

Create a container for every child item, create a carousel container that references them, then publish the carousel container.

async function publishCarousel(igAccountId, carouselData) {
  const children = [];

  for (const item of carouselData.items) {
    const container = await instagramRequest(`/${igAccountId}/media`, {
      method: 'POST',
      [item.type === 'video' ? 'video_url' : 'image_url']: item.url,
      caption: item.caption || '',
      is_carousel_item: 'true'
    });

    children.push(container.id);
  }

  const carouselContainer = await instagramRequest(`/${igAccountId}/media`, {
    method: 'POST',
    media_type: 'CAROUSEL',
    children: children.join(','),
    caption: carouselData.caption
  });

  return instagramRequest(`/${igAccountId}/media_publish`, {
    method: 'POST',
    creation_id: carouselContainer.id
  });
}

// Usage
const carousel = await publishCarousel('17841400000000000', {
  caption: 'Product showcase 2026',
  items: [
    {
      type: 'image',
      url: 'https://example.com/img1.jpg',
      caption: 'Product 1'
    },
    {
      type: 'image',
      url: 'https://example.com/img2.jpg',
      caption: 'Product 2'
    },
    {
      type: 'video',
      url: 'https://example.com/vid1.mp4',
      caption: 'Demo'
    }
  ]
});

console.log(`Published carousel ID: ${carousel.id}`);

Media types

Media type	Parameters	Use case
`IMAGE`	`image_url`, `caption`	Photo posts
`VIDEO`	`video_url`, `cover_url`, `caption`	Video posts
`REELS`	`video_url`, `cover_url`, `caption`, `share_to_feed`	Reels
`CAROUSEL`	`children`, `caption`	Multiple media items

Retrieving Media and Insights

Get published media

async function getUserMedia(igAccountId, limit = 25) {
  return instagramRequest(`/${igAccountId}/media`, {
    fields: [
      'id',
      'caption',
      'media_type',
      'media_url',
      'permalink',
      'timestamp',
      'like_count',
      'comments_count'
    ].join(','),
    limit
  });
}

// Usage
const media = await getUserMedia('17841400000000000');

for (const item of media.data) {
  console.log(`${item.media_type}: ${item.caption}`);
  console.log(`Likes: ${item.like_count}, Comments: ${item.comments_count}`);
  console.log(`URL: ${item.permalink}`);
}

Get media insights

async function getMediaInsights(mediaId) {
  return instagramRequest(`/${mediaId}/insights`, {
    fields: 'impressions,reach,engagement,saved,video_views,profile_visits,follows'
  });
}

// Usage
const insights = await getMediaInsights('17890000000000000');

for (const metric of insights.data) {
  console.log(`${metric.name}: ${metric.values[0].value}`);
}

Available media metrics

Metric	Description	Media types
`impressions`	Total views	All
`reach`	Unique accounts reached	All
`engagement`	Likes, comments, and saves	All
`saved`	Times saved	All
`video_views`	Video views of 3+ seconds	Video, Reels
`plays`	Total video plays	Video, Reels
`profile_visits`	Profile visits from a post	All
`follows`	Follows from a post	All
`comments`	Comment count	All
`like_count`	Like count	All

Get account insights

async function getAccountInsights(
  igAccountId,
  metricNames,
  since = null,
  until = null
) {
  const params = {
    metric: metricNames.join(','),
    period: 'day'
  };

  if (since) params.since = since;
  if (until) params.until = until;

  return instagramRequest(`/${igAccountId}/insights`, params);
}

// Usage: get 30 days of metrics
const accountInsights = await getAccountInsights(
  '17841400000000000',
  [
    'impressions',
    'reach',
    'profile_views',
    'email_contacts',
    'website_clicks'
  ],
  '2026-02-23',
  '2026-03-25'
);

for (const metric of accountInsights.data) {
  console.log(`${metric.name}:`);

  for (const value of metric.values) {
    console.log(`  ${value.end_time}: ${value.value}`);
  }
}

Account-level metrics

Metric	Description
`impressions`	Total profile and content views
`reach`	Unique accounts reached
`profile_views`	Profile visits
`website_clicks`	Link-in-bio clicks
`email_contacts`	Email button taps
`phone_call_clicks`	Phone button taps
`text_message_clicks`	SMS button taps
`get_directions_clicks`	Address clicks
`follower_count`	Total followers
`audience_city`	Follower cities
`audience_country`	Follower countries
`audience_gender_age`	Demographic breakdown

Comment Management

Get comments for a media item

async function getMediaComments(mediaId, limit = 50) {
  return instagramRequest(`/${mediaId}/comments`, {
    fields: 'id,text,timestamp,username,hidden',
    limit
  });
}

// Usage
const comments = await getMediaComments('17890000000000000');

for (const comment of comments.data) {
  console.log(`@${comment.username}: ${comment.text}`);
  console.log(`Hidden: ${comment.hidden}`);
}

Reply to a comment

async function replyToComment(mediaId, commentId, replyText) {
  return instagramRequest(`/${mediaId}/comments`, {
    method: 'POST',
    response_to: commentId,
    message: replyText
  });
}

// Usage
const reply = await replyToComment(
  '17890000000000000',
  '17900000000000000',
  'Thank you for your interest! Check your DM for details.'
);

console.log(`Reply posted: ${reply.id}`);

Hide a comment

async function hideComment(commentId) {
  return instagramRequest(`/${commentId}`, {
    method: 'POST',
    hide: 'true'
  });
}

// Usage
await hideComment('17900000000000000');
console.log('Comment hidden');

Delete a comment

async function deleteComment(commentId) {
  await instagramRequest(`/${commentId}`, {
    method: 'DELETE'
  });

  console.log('Comment deleted');
}

Webhooks

Webhooks reduce polling and let your application react to comments, mentions, and message reactions in real time.

Configure webhook subscriptions

async function subscribeToWebhooks(appId, accessToken) {
  const response = await fetch(
    `https://graph.facebook.com/v18.0/${appId}/subscriptions`,
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        object: 'instagram',
        callback_url: 'https://myapp.com/webhooks/instagram',
        verify_token: process.env.WEBHOOK_VERIFY_TOKEN,
        access_token: accessToken,
        fields: ['comments', 'mentions', 'message_reactions']
      })
    }
  );

  return response.json();
}

Verify and handle webhook events

Return the challenge during the verification request. For incoming events, validate the event object and acknowledge the request after processing.

const express = require('express');

const app = express();

app.get('/webhooks/instagram', (req, res) => {
  const mode = req.query['hub.mode'];
  const token = req.query['hub.verify_token'];
  const challenge = req.query['hub.challenge'];

  if (mode === 'subscribe' && token === process.env.WEBHOOK_VERIFY_TOKEN) {
    console.log('Webhook verified');
    return res.status(200).send(challenge);
  }

  return res.status(403).send('Verification failed');
});

app.post('/webhooks/instagram', express.json(), async (req, res) => {
  const body = req.body;

  if (body.object !== 'instagram') {
    return res.status(404).send('Not found');
  }

  for (const entry of body.entry) {
    for (const change of entry.changes) {
      switch (change.field) {
        case 'comments':
          await handleNewComment(change.value);
          break;
        case 'mentions':
          await handleMention(change.value);
          break;
        case 'message_reactions':
          await handleReaction(change.value);
          break;
      }
    }
  }

  return res.status(200).send('OK');
});

async function handleNewComment(data) {
  console.log(`New comment on media ${data.media_id}`);
  console.log(`From: ${data.from_id}`);
  console.log(`Text: ${data.text}`);

  if (isSpam(data.text)) {
    await hideComment(data.id);
  }
}

Webhook fields

Field	Trigger
`comments`	New comment or reply
`mentions`	A user mentions the account
`message_reactions`	Reaction to a story
`story_status`	Story reply or view

Rate Limiting

Understand the limits

Instagram Graph API enforces:

200 calls per hour per app, shared across users
200 Business Discovery calls per hour per user
Content publishing limits based on action type

Exceeding a limit results in HTTP 400 with error subcode 613.

Apply rate-limit best practices

Cache responses instead of repeatedly fetching unchanged data.
Use field expansion to reduce request counts.
Prefer webhooks over polling.
Queue requests when processing many accounts.
Retry transient failures with exponential backoff.

async function makeRateLimitedRequest(
  endpoint,
  params = {},
  maxRetries = 3
) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      return await instagramRequest(endpoint, params);
    } catch (error) {
      const isRateLimited =
        error.message.includes('429') || error.message.includes('613');

      if (!isRateLimited || attempt === maxRetries) {
        throw error;
      }

      const delay = 2 ** attempt * 1000;

      console.log(`Rate limited. Retrying in ${delay}ms...`);
      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }
}

Troubleshooting Common Issues

OAuth token expired

Symptoms: Invalid OAuth access token errors.

Fix:

Track the 60-day token expiration time.
Alert users before expiration.
Implement token refresh before expiry.
Re-authenticate the user if the token has expired.

Media publishing fails

Symptoms: The publishing request returns an error.

Fix:

Ensure the image or video URL is publicly accessible without authentication.
Verify image format is JPEG or PNG and smaller than 8 MB.
Verify video format is MP4, smaller than 1 GB, and shorter than 90 seconds.
Poll video processing status before publishing the container.

Insights are unavailable

Symptoms: The Insights API returns empty data.

Fix:

Confirm that the account is Business or Creator, not Personal.
Allow 24–48 hours for insights to populate.
Check that the account has sufficient activity.

Production Deployment Checklist

Before going live:

[ ] Convert all test accounts to Business or Creator accounts.
[ ] Implement OAuth 2.0 with long-lived tokens.
[ ] Encrypt tokens at rest.
[ ] Track expiration and implement token refresh.
[ ] Expose webhook endpoints over HTTPS.
[ ] Add request queuing and rate-limit handling.
[ ] Implement structured API error handling.
[ ] Log API requests and responses securely.
[ ] Create content moderation workflows.
[ ] Test across multiple account types.

Real-World Use Cases

Social media scheduling tool

A marketing platform can automate posting across 50+ client accounts.

Implementation approach:

Build a content calendar with drag-and-drop scheduling.
Store approved media URLs and captions.
Create a publishing job for each scheduled item.
Publish photos, videos, reels, and carousels through the content publishing flow.
Add hashtag suggestions based on content.

Outcome: Less manual publishing work and a more consistent posting schedule.

Customer service automation

An e-commerce brand can respond to common questions through comment webhooks.

Implementation approach:

Subscribe to the comments webhook field.
Detect keywords such as price, availability, and shipping.
Reply with product links for known questions.
Route complex questions to a human support queue.
Hide spam or inappropriate comments automatically.

Outcome: Faster responses while reserving human support time for complex requests.

Conclusion

The Instagram Graph API provides programmatic access to Instagram Business and Creator account workflows.

Key implementation takeaways:

Authenticate with Facebook Login OAuth 2.0 and use 60-day long-lived tokens.
Publish photos, videos, reels, and carousels through media containers.
Use media and account insights for engagement and reach reporting.
Use webhooks for real-time comment and mention handling.
Design around the 200-calls-per-hour-per-app rate limit.
Use API testing and collaboration tools such as Apidog to validate requests and OAuth flows.

FAQ

How do I get access to the Instagram API?

Create a Facebook Developer account, create a Business app, add the Instagram Graph API product, and authenticate users through Facebook Login with the required permissions.

Can I post to Instagram automatically?

Yes. Use the Content Publishing API to publish photos, videos, reels, and carousels for Business and Creator accounts.

What Instagram account types support the API?

Business and Creator accounts have full API access. Personal accounts have limited or no API access.

How do I get Instagram comments?

Use the /{media-id}/comments endpoint to retrieve comments for a specific media item. Use webhooks for real-time comment notifications.

What are Instagram rate limits?

The Instagram Graph API allows 200 calls per hour per app. Some endpoints also have additional per-user limits.

Can I publish Stories through the API?

Yes. Stories can be published through the same content publishing flow used for feed posts.

How do I access Instagram Insights?

Request instagram_manage_insights during OAuth, then use the Insights endpoint to retrieve media and account metrics.

Can I reply to comments automatically?

Yes. Use the Comments API to create replies. This is commonly used for automated customer service workflows.

How to Use AWS Lambda API for Serverless in 2026

Preecha — Tue, 14 Jul 2026 01:02:43 +0000

TL;DR

The AWS Lambda API lets you deploy, manage, and invoke serverless functions programmatically. It uses IAM authentication, RESTful endpoints for function management, synchronous and asynchronous invocation modes, and account-level concurrency limits. This guide covers authentication, deployment, invocation patterns, event source mappings, layers, and production deployment strategies.

Try Apidog today

Introduction

AWS Lambda processes trillions of requests monthly for over 1 million active users. If you build serverless applications, automation tools, or event-driven systems, Lambda API integration is essential for infrastructure as code and CI/CD pipelines.

Teams managing 50+ Lambda functions manually can lose 10–15 hours each week to deployments, configuration changes, and monitoring. Automating Lambda through its API helps you standardize deployments, implement blue-green releases, and adjust capacity as demand changes.

This guide shows how to:

Authenticate with IAM and AWS Signature Version 4 (SigV4)
Create, update, and delete functions
Invoke functions synchronously and asynchronously
Publish versions and route traffic with aliases
Configure SQS and DynamoDB event source mappings
Share dependencies through Lambda layers
Set reserved concurrency for critical workloads

What Is the AWS Lambda API?

AWS Lambda exposes a RESTful API for managing serverless compute functions.

You can use it to:

Create, update, and delete functions
Deploy and version function code
Invoke functions synchronously or asynchronously
Configure event sources such as SQS, Kinesis, DynamoDB, and S3
Publish and attach layers
Manage aliases and weighted traffic routing
Configure reserved concurrency
Integrate logging and monitoring workflows

Key Features

Feature	Description
RESTful API	Standard HTTPS endpoints
IAM authentication	AWS Signature Version 4
Async invocation	Fire-and-forget event processing
Sync invocation	Request-response execution
Event sources	200+ AWS service integrations
Layers	Shared code and dependencies
Versions and aliases	Traffic shifting and rollbacks
Provisioned concurrency	Reduce cold starts

Lambda Runtime Support

Runtime	Versions	Use case
Node.js	18.x, 20.x	API backends, event processing
Python	3.9, 3.10, 3.11	Data processing, ML inference
Java	11, 17, 21	Enterprise applications
Go	1.x	High-performance APIs
Rust	1.x	Low-latency functions
.NET	6, 8	Windows workloads
Ruby	3.x	Web applications
Custom	Any	Container-based runtimes

API Architecture Overview

Lambda service endpoints follow this format:

https://lambda.{region}.amazonaws.com/2015-03-31/

For example, the Lambda endpoint in us-east-1 is:

https://lambda.us-east-1.amazonaws.com/2015-03-31/

API Versions

Version	Status	Use case
`2015-03-31`	Current	All Lambda operations
`2018-01-31`	Runtime API	Custom runtime interface

Getting Started: Authentication Setup

Step 1: Create an AWS Account and IAM User

Before calling the Lambda API:

Create an AWS account.
Open the IAM console.
Go to Users → Create user.
Attach the Lambda execution and deployment policies required by your workflow.

Use least-privilege IAM policies. A deployment identity usually needs permissions such as function creation, code updates, configuration updates, version publishing, alias management, and event source mapping management.

Step 2: Generate IAM Credentials

Create an access key for programmatic access:

aws iam create-access-key --user-name lambda-deployer

Example response:

{
  "AccessKey": {
    "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  }
}

Store credentials securely.

Use an AWS credentials profile:

# ~/.aws/credentials
[lambda-deployer]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Or use environment variables:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="us-east-1"

Step 3: Understand AWS Signature Version 4

Every direct Lambda API request must be signed with SigV4.

The signing flow is:

Create a canonical request.
Create the string to sign.
Derive a signing key and calculate the signature.
Add the authorization headers.

const crypto = require('crypto');

class AWSSigner {
  constructor(accessKeyId, secretAccessKey, region, service = 'lambda') {
    this.accessKeyId = accessKeyId;
    this.secretAccessKey = secretAccessKey;
    this.region = region;
    this.service = service;
  }

  sign(request, body = null) {
    const now = new Date();
    const amzDate = now.toISOString().replace(/[:-]|\.\d{3}/g, '');
    const dateStamp = amzDate.slice(0, 8);

    // 1. Create the canonical request.
    const hashedPayload = body
      ? crypto.createHash('sha256').update(body).digest('hex')
      : 'UNSIGNED-PAYLOAD';

    const canonicalUri = request.path;
    const canonicalQuerystring = request.query || '';
    const canonicalHeaders = `host:${request.host}\nx-amz-date:${amzDate}\n`;
    const signedHeaders = 'host;x-amz-date';

    const canonicalRequest = [
      request.method,
      canonicalUri,
      canonicalQuerystring,
      canonicalHeaders,
      signedHeaders,
      hashedPayload
    ].join('\n');

    // 2. Create the string to sign.
    const algorithm = 'AWS4-HMAC-SHA256';
    const credentialScope = `${dateStamp}/${this.region}/${this.service}/aws4_request`;

    const requestHash = crypto
      .createHash('sha256')
      .update(canonicalRequest)
      .digest('hex');

    const stringToSign = [
      algorithm,
      amzDate,
      credentialScope,
      requestHash
    ].join('\n');

    // 3. Calculate the signature.
    const kDate = this.hmac(`AWS4${this.secretAccessKey}`, dateStamp);
    const kRegion = this.hmac(kDate, this.region);
    const kService = this.hmac(kRegion, this.service);
    const kSigning = this.hmac(kService, 'aws4_request');
    const signature = this.hmac(kSigning, stringToSign, 'hex');

    // 4. Add the authorization headers.
    const authorizationHeader =
      `${algorithm} Credential=${this.accessKeyId}/${credentialScope}, ` +
      `SignedHeaders=${signedHeaders}, Signature=${signature}`;

    return {
      Authorization: authorizationHeader,
      'X-Amz-Date': amzDate,
      'X-Amz-Content-Sha256': hashedPayload
    };
  }

  hmac(key, value, encoding = 'buffer') {
    return crypto.createHmac('sha256', key).update(value).digest(encoding);
  }
}

const signer = new AWSSigner(
  process.env.AWS_ACCESS_KEY_ID,
  process.env.AWS_SECRET_ACCESS_KEY,
  'us-east-1'
);

For production workloads, prefer the AWS SDK. It handles SigV4 signing automatically and avoids maintaining custom signing code.

Step 4: Create a Lambda API Client

If you need to call the REST API directly, wrap requests in a reusable helper.

const LAMBDA_BASE_URL =
  'https://lambda.us-east-1.amazonaws.com/2015-03-31';

const lambdaRequest = async (path, options = {}) => {
  const url = new URL(`${LAMBDA_BASE_URL}${path}`);
  const method = options.method || 'GET';
  const body = options.body ? JSON.stringify(options.body) : null;

  const signer = new AWSSigner(
    process.env.AWS_ACCESS_KEY_ID,
    process.env.AWS_SECRET_ACCESS_KEY,
    'us-east-1'
  );

  const headers = signer.sign(
    {
      method,
      host: 'lambda.us-east-1.amazonaws.com',
      path
    },
    body
  );

  const response = await fetch(url.toString(), {
    method,
    headers: {
      'Content-Type': 'application/json',
      ...headers,
      ...options.headers
    },
    body
  });

  if (!response.ok) {
    const error = await response.json();
    throw new Error(`Lambda API Error: ${error.Message}`);
  }

  return response.json();
};

// List deployed functions.
const functions = await lambdaRequest('/functions');
console.log(`Found ${functions.Functions.length} functions`);

Alternative: Use the AWS SDK

For production code, use AWS SDK for JavaScript v3.

npm install @aws-sdk/client-lambda

const {
  LambdaClient,
  ListFunctionsCommand,
  CreateFunctionCommand,
  InvokeCommand
} = require('@aws-sdk/client-lambda');

const lambda = new LambdaClient({
  region: 'us-east-1'
});

// List functions.
const result = await lambda.send(new ListFunctionsCommand({}));

// Create a function.
const createCommand = new CreateFunctionCommand({
  FunctionName: 'my-function',
  Runtime: 'nodejs20.x',
  Role: 'arn:aws:iam::123456789012:role/lambda-execution-role',
  Handler: 'index.handler',
  Code: {
    S3Bucket: 'my-bucket',
    S3Key: 'function.zip'
  }
});

const fn = await lambda.send(createCommand);
console.log(fn.FunctionArn);

Function Management

Create a Function

Create a Lambda function from a deployment artifact stored in S3.

const createFunction = async (functionConfig) => {
  return lambdaRequest('/functions', {
    method: 'POST',
    body: {
      FunctionName: functionConfig.name,
      Runtime: functionConfig.runtime || 'nodejs20.x',
      Role: functionConfig.roleArn,
      Handler: functionConfig.handler || 'index.handler',
      Code: {
        S3Bucket: functionConfig.s3Bucket,
        S3Key: functionConfig.s3Key
      },
      Description: functionConfig.description || '',
      Timeout: functionConfig.timeout || 3,
      MemorySize: functionConfig.memorySize || 128,
      Environment: {
        Variables: functionConfig.environment || {}
      },
      Tags: functionConfig.tags || {}
    }
  });
};

const fn = await createFunction({
  name: 'order-processor',
  roleArn: 'arn:aws:iam::123456789012:role/lambda-execution-role',
  handler: 'index.handler',
  runtime: 'nodejs20.x',
  s3Bucket: 'my-deployments-bucket',
  s3Key: 'order-processor/v1.0.0.zip',
  description: 'Process orders from SQS queue',
  timeout: 30,
  memorySize: 512,
  environment: {
    DB_HOST: 'db.example.com',
    LOG_LEVEL: 'info'
  }
});

console.log(`Function created: ${fn.FunctionArn}`);

Upload Code Directly

For small deployment packages under 50 MB when zipped, include the ZIP file directly in the API request.

const fs = require('fs');

const createFunctionWithZip = async (functionName, zipPath) => {
  const zipBuffer = fs.readFileSync(zipPath);
  const base64Code = zipBuffer.toString('base64');

  return lambdaRequest('/functions', {
    method: 'POST',
    body: {
      FunctionName: functionName,
      Runtime: 'nodejs20.x',
      Role: 'arn:aws:iam::123456789012:role/lambda-execution-role',
      Handler: 'index.handler',
      Code: {
        ZipFile: base64Code
      }
    }
  });
};

Package your function first:

zip -r function.zip index.js node_modules/

Then create it:

await createFunctionWithZip('my-function', './function.zip');

Update Function Code

Deploy a new artifact and optionally publish an immutable version.

const updateFunctionCode = async (functionName, updateConfig) => {
  return lambdaRequest(`/functions/${functionName}/code`, {
    method: 'PUT',
    body: {
      S3Bucket: updateConfig.s3Bucket,
      S3Key: updateConfig.s3Key,
      Publish: updateConfig.publish || false
    }
  });
};

const updated = await updateFunctionCode('order-processor', {
  s3Bucket: 'my-deployments-bucket',
  s3Key: 'order-processor/v1.1.0.zip',
  publish: true
});

console.log(`Updated to version: ${updated.Version}`);

Update Function Configuration

Use the configuration endpoint to modify runtime settings, memory, timeout, environment variables, and handler configuration.

const updateFunctionConfig = async (functionName, config) => {
  return lambdaRequest(`/functions/${functionName}/configuration`, {
    method: 'PUT',
    body: {
      Runtime: config.runtime,
      Handler: config.handler,
      Description: config.description,
      Timeout: config.timeout,
      MemorySize: config.memorySize,
      Environment: {
        Variables: config.environment
      }
    }
  });
};

await updateFunctionConfig('order-processor', {
  timeout: 60,
  memorySize: 1024,
  environment: {
    DB_HOST: 'new-db.example.com',
    LOG_LEVEL: 'debug'
  }
});

Delete a Function

Delete an entire function or a specific qualified version.

const deleteFunction = async (functionName, qualifier = null) => {
  const path = qualifier
    ? `/functions/${functionName}?Qualifier=${qualifier}`
    : `/functions/${functionName}`;

  await lambdaRequest(path, { method: 'DELETE' });
  console.log(`Function ${functionName} deleted`);
};

Function Invocation

Synchronous Invocation: Request-Response

Use RequestResponse when the caller needs the function result immediately, such as an API request or CLI command.

const invokeFunction = async (functionName, payload, qualifier = null) => {
  const path = qualifier
    ? `/functions/${functionName}/invocations?Qualifier=${qualifier}`
    : `/functions/${functionName}/invocations`;

  const response = await lambdaRequest(path, {
    method: 'POST',
    headers: {
      'X-Amz-Invocation-Type': 'RequestResponse',
      'X-Amz-Log-Type': 'Tail'
    },
    body: payload
  });

  const result = JSON.parse(Buffer.from(response.Payload).toString());
  const logs = Buffer.from(response.LogResult, 'base64').toString();

  return { result, logs };
};

const { result, logs } = await invokeFunction('order-processor', {
  orderId: 'ORD-12345',
  customerId: 'CUST-67890',
  items: [
    { sku: 'PROD-001', quantity: 2 },
    { sku: 'PROD-002', quantity: 1 }
  ]
});

console.log(`Result: ${JSON.stringify(result)}`);
console.log(`Logs:\n${logs}`);

Asynchronous Invocation: Fire-and-Forget

Use Event invocation for background work such as email delivery, notifications, or event processing.

const invokeAsync = async (functionName, payload) => {
  const response = await lambdaRequest(
    `/functions/${functionName}/invocations`,
    {
      method: 'POST',
      headers: {
        'X-Amz-Invocation-Type': 'Event',
        'X-Amz-Log-Type': 'None'
      },
      body: payload
    }
  );

  return {
    statusCode: response.StatusCode,
    executionId: response['X-Amz-Execution-Id']
  };
};

const result = await invokeAsync('email-sender', {
  to: 'customer@example.com',
  template: 'order-confirmation',
  data: {
    orderId: 'ORD-12345'
  }
});

console.log(`Async invocation ID: ${result.executionId}`);

Dry Run Invocation

Use DryRun to validate IAM permissions without running the function.

const dryRunInvocation = async (functionName) => {
  return lambdaRequest(`/functions/${functionName}/invocations`, {
    method: 'POST',
    headers: {
      'X-Amz-Invocation-Type': 'DryRun'
    }
  });
};

try {
  await dryRunInvocation('order-processor');
  console.log('Invocation permissions OK');
} catch (error) {
  console.error('Permission denied:', error.message);
}

Invocation Response Types

Invocation type	Behavior	Use case
`RequestResponse`	Synchronous; waits for the result	API calls, CLI commands
`Event`	Asynchronous; returns immediately	Notifications, background processing
`DryRun`	Validates permissions only	Validation, debugging

Version and Alias Management

Publish a Version

A published Lambda version is an immutable snapshot of your function code and configuration.

const publishVersion = async (functionName, description = null) => {
  return lambdaRequest(`/functions/${functionName}/versions`, {
    method: 'POST',
    body: description ? { Description: description } : {}
  });
};

const version = await publishVersion(
  'order-processor',
  'v1.2.0 - Add tax calculation'
);

console.log(`Published version: ${version.Version}`);

Create an Alias

An alias is a named pointer to a specific Lambda version.

const createAlias = async (
  functionName,
  aliasName,
  version,
  description = null
) => {
  return lambdaRequest(`/functions/${functionName}/aliases`, {
    method: 'POST',
    body: {
      Name: aliasName,
      FunctionVersion: version,
      Description: description
    }
  });
};

const prodAlias = await createAlias(
  'order-processor',
  'prod',
  '5',
  'Production version'
);

console.log(`Alias ARN: ${prodAlias.AliasArn}`);

Shift Traffic with Alias Routing

Use weighted routing to direct a percentage of traffic to a new function version.

const updateAliasWithRouting = async (
  functionName,
  aliasName,
  routingConfig
) => {
  return lambdaRequest(
    `/functions/${functionName}/aliases/${aliasName}`,
    {
      method: 'PUT',
      body: {
        RoutingConfig: {
          AdditionalVersionWeights: routingConfig
        }
      }
    }
  );
};

// Route 10% of traffic to version 6.
await updateAliasWithRouting('order-processor', 'prod', {
  '6': 0.1
});

// After validation, remove weighted routing.
await updateAliasWithRouting('order-processor', 'prod', {});

Common Alias Patterns

Alias	Version	Purpose
`dev`	`$LATEST`	Development testing
`staging`	Latest tested version	QA validation
`prod`	Stable version	Production traffic
`blue`	Current production version	Blue-green deployment
`green`	New version	Blue-green deployment

Event Source Mapping

Event source mappings connect services that produce records—such as SQS, Kinesis, and DynamoDB Streams—to Lambda functions.

Create an SQS Trigger

const createSQSEventSource = async (
  functionName,
  queueArn,
  batchSize = 10
) => {
  return lambdaRequest('/event-source-mappings', {
    method: 'POST',
    body: {
      EventSourceArn: queueArn,
      FunctionName: functionName,
      BatchSize: batchSize,
      Enabled: true
    }
  });
};

const mapping = await createSQSEventSource(
  'order-processor',
  'arn:aws:sqs:us-east-1:123456789012:orders-queue',
  10
);

console.log(`Event source created: ${mapping.UUID}`);

Create a DynamoDB Stream Trigger

const createDynamoDBEventSource = async (
  functionName,
  streamArn,
  startingPosition = 'LATEST'
) => {
  return lambdaRequest('/event-source-mappings', {
    method: 'POST',
    body: {
      EventSourceArn: streamArn,
      FunctionName: functionName,
      StartingPosition: startingPosition,
      BatchSize: 100,
      BisectBatchOnFunctionError: true,
      MaximumRetryAttempts: 3
    }
  });
};

await createDynamoDBEventSource(
  'user-analytics',
  'arn:aws:dynamodb:us-east-1:123456789012:table/Users/stream/2026-03-25T00:00:00.000'
);

Event Source Types

Source	Use case	Batch support
SQS	Message queues	Yes, 1–10
Kinesis	Real-time streams	Yes, 1–10,000
DynamoDB Streams	Database changes	Yes, 1–1,000
S3	Object events	No, one event at a time
EventBridge	Event routing	Yes
API Gateway	HTTP APIs	No
Schedule	Cron jobs	No

Layer Management

Layers package shared dependencies separately from function code. Use them to avoid duplicating common utilities across functions.

Create a Layer

const createLayer = async (layerName, layerConfig) => {
  return lambdaRequest('/layers', {
    method: 'POST',
    body: {
      LayerName: layerName,
      Description: layerConfig.description,
      CompatibleRuntimes: layerConfig.runtimes,
      Content: {
        S3Bucket: layerConfig.s3Bucket,
        S3Key: layerConfig.s3Key
      }
    }
  });
};

const layer = await createLayer('shared-utils', {
  description: 'Shared utilities and dependencies',
  runtimes: ['nodejs20.x', 'nodejs18.x'],
  s3Bucket: 'my-layers-bucket',
  s3Key: 'shared-utils/v1.zip'
});

console.log(`Layer ARN: ${layer.LayerArn}`);

Attach Layers to a Function

const createFunctionWithLayers = async (functionConfig) => {
  return lambdaRequest('/functions', {
    method: 'POST',
    body: {
      FunctionName: functionConfig.name,
      Runtime: functionConfig.runtime,
      Role: functionConfig.roleArn,
      Handler: functionConfig.handler,
      Code: {
        S3Bucket: functionConfig.s3Bucket,
        S3Key: functionConfig.s3Key
      },
      Layers: functionConfig.layers
    }
  });
};

await createFunctionWithLayers({
  name: 'api-handler',
  roleArn: 'arn:aws:iam::123456789012:role/lambda-execution-role',
  handler: 'index.handler',
  runtime: 'nodejs20.x',
  s3Bucket: 'my-deployments-bucket',
  s3Key: 'api-handler/v1.0.0.zip',
  layers: [
    'arn:aws:lambda:us-east-1:123456789012:layer:shared-utils:1',
    'arn:aws:lambda:us-east-1:123456789012:layer:aws-sdk:3'
  ]
});

Concurrency and Scaling

Set Reserved Concurrency

Reserved concurrency allocates a number of concurrent execution slots to one function. Use it to protect critical workloads from account-level contention.

const putFunctionConcurrency = async (
  functionName,
  reservedConcurrentExecutions
) => {
  return lambdaRequest(`/functions/${functionName}/concurrency`, {
    method: 'PUT',
    body: {
      ReservedConcurrentExecutions: reservedConcurrentExecutions
    }
  });
};

await putFunctionConcurrency('order-processor', 100);

Account Concurrency Limits

Account type	Default limit	Increase available
Free Tier	1,000	Yes
Pay-as-you-go	1,000	Yes
Enterprise	1,000+	Custom limits

Production Deployment Checklist

Before deploying a Lambda integration to production, verify the following:

[ ] Use the AWS SDK for automatic SigV4 signing.
[ ] Publish immutable versions for every release.
[ ] Route production traffic through aliases.
[ ] Configure reserved concurrency for critical functions.
[ ] Set up dead-letter queues (DLQs) for asynchronous invocations.
[ ] Enable X-Ray tracing for debugging.
[ ] Configure VPC networking when functions need database access.
[ ] Emit structured JSON logs.
[ ] Create CloudWatch alarms for errors, throttles, and queue depth.
[ ] Use layers for shared dependencies.
[ ] Implement a blue-green deployment strategy.

Real-World Use Cases

API Backend

A SaaS company builds a serverless REST API.

Challenge: Variable traffic and unpredictable scaling
Solution: Lambda with API Gateway and automatic scaling
Result: 99.99% uptime and 60% cost reduction compared with EC2

Implementation components:

Lambda functions per resource
API Gateway for routing and authentication
DynamoDB for data storage
Provisioned concurrency for consistent latency

Event Processing Pipeline

An e-commerce platform processes orders through an event-driven workflow.

Challenge: Order spikes during sales events
Solution: SQS with Lambda batch processing
Result: Zero lost orders and 10x spike handling

Implementation components:

An SQS queue buffers incoming orders.
Lambda processes 10 messages per batch.
A DLQ captures failed messages.
CloudWatch alerts monitor queue depth.

Conclusion

The AWS Lambda API provides the building blocks for programmatic serverless deployments and operations.

Key takeaways:

Authenticate with IAM and SigV4; prefer the AWS SDK for signing.
Use synchronous invocations when callers need immediate results.
Use asynchronous invocations for background event processing.
Publish versions and use aliases for safer deployments and traffic shifting.
Connect event sources to build event-driven systems.
Use layers to share dependencies.
Configure concurrency controls for critical workloads.
Apidog streamlines API testing and team collaboration.

FAQ

How do I authenticate with the Lambda API?

Use AWS IAM credentials with Signature Version 4 signing. The AWS SDK handles signing automatically.

What is the difference between synchronous and asynchronous invocation?

Synchronous invocation (RequestResponse) waits for function completion and returns a result. Asynchronous invocation (Event) queues the request and returns immediately.

How do Lambda versions work?

Each published version is an immutable snapshot of a function. Use aliases to point to versions and shift traffic between releases.

What are Lambda Layers?

Layers package code and dependencies separately from function code, allowing multiple functions to reuse shared libraries.

How do I reduce cold starts?

Use provisioned concurrency, smaller deployment packages, and compiled languages such as Go or Rust for latency-critical functions.

What is reserved concurrency?

Reserved concurrency guarantees execution slots for a specific function and helps prevent noisy-neighbor issues.

Can I trigger Lambda from S3?

Yes. Configure S3 event notifications to invoke a Lambda function when objects are created or deleted.

How Do You Build a HIPAA-Compliant API in 2026 for Secure Healthcare Applications?

Preecha — Mon, 13 Jul 2026 13:02:48 +0000

TL;DR

HIPAA compliance for APIs requires strict safeguards for Protected Health Information (PHI): encryption in transit and at rest, audit logging, access controls, and Business Associate Agreements (BAAs). This guide shows how to implement a HIPAA-focused API architecture, authentication, authorization, audit trails, and compliance verification.

Try Apidog today

Introduction

Healthcare data breaches cost an average of $10.93 million per incident. If you build healthcare applications, API security is not optional: it is part of meeting HIPAA (Health Insurance Portability and Accountability Act) requirements.

Unauthorized API and application access is involved in 79% of healthcare data breaches. A properly designed HIPAA-compliant API architecture helps prevent unauthorized access, creates an auditable record of PHI activity, and protects patient privacy.

This guide covers:

PHI classification and the minimum necessary standard
BAAs and vendor review
MFA, JWTs, and role-based authorization
TLS and encryption at rest
Audit logging and retention
Input validation, rate limiting, and error handling
Deployment and risk-assessment checklists

💡 Design secure endpoints, validate encryption requirements, audit access patterns, and document compliance controls in one workspace with Apidog. Share API specifications with your compliance team and maintain audit-ready documentation.

What Is HIPAA and Why Does It Matter for APIs?

HIPAA is a US federal law that establishes standards for protecting sensitive patient health information. For APIs, the HIPAA Security Rule applies to electronic Protected Health Information (ePHI) created, received, maintained, or transmitted by your application.

Who Must Comply

Entity type	Examples	API implications
Covered entities	Healthcare providers, health plans, clearinghouses	Direct HIPAA liability
Business associates	API providers, cloud services, software vendors	BAA required; direct liability
Subcontractors	Subprocessors, downstream API services	BAA required

Key HIPAA Rules for APIs

Privacy Rule

Governs the use and disclosure of PHI
Requires the minimum necessary standard
Provides patient access rights
Defines authorization requirements

Security Rule

Requires safeguards for ePHI
Access controls
Audit controls
Integrity controls
Transmission security

Breach Notification Rule

Defines incident-response requirements
Requires risk-assessment documentation
Includes a 60-day notification window
Requires mitigation procedures

API Architecture Overview

A HIPAA-oriented API stack should place controls at every layer:

┌─────────────────────────────────────────────────────────────────┐
│                    HIPAA-COMPLIANT API STACK                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐          │
│  │   CLIENT    │───▶│ API GATEWAY │───▶│  DATABASE   │          │
│  │   (App)     │    │             │    │ (Encrypted) │          │
│  └─────────────┘    └─────────────┘    └─────────────┘          │
│        │                  │                  │                   │
│        ▼                  ▼                  ▼                   │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐          │
│  │ OAuth 2.0   │    │ WAF + Rate  │    │ Audit       │          │
│  │ + MFA       │    │ Limiting    │    │ Logging     │          │
│  └─────────────┘    └─────────────┘    └─────────────┘          │
│                                                                  │
│  Encrypt data in transit with TLS 1.3+ and at rest with AES-256 │
└─────────────────────────────────────────────────────────────────┘

Getting Started: Build the Compliance Foundation

Step 1: Execute Business Associate Agreements

Before your API handles PHI:

Identify every vendor that can access, process, store, transmit, back up, or log PHI.
Execute a BAA with each applicable vendor.
Document downstream subprocessors.
Review BAAs annually and whenever your architecture changes.

Common vendors that may require BAAs:

Cloud hosting providers such as AWS, GCP, and Azure
Database providers
Logging and SIEM services
Backup providers
API gateways
Monitoring and alerting tools

Do not use the following for PHI unless an appropriate BAA and configuration are in place:

Standard Google Analytics
Free-tier cloud services
Personal email accounts
Non-healthcare Slack channels

Step 2: Classify API Data

Create a data inventory before implementing endpoints. Mark each field as PHI, then apply the appropriate controls.

Data type	Classification	Protection level
Patient name + date of birth	PHI	Full HIPAA controls
Medical record number	PHI	Full HIPAA controls
Diagnosis codes (ICD-10)	PHI	Full HIPAA controls
Treatment notes	PHI	Full HIPAA controls
Appointment times without patient identifiers	Not PHI	Standard controls
Aggregated, de-identified data	Not PHI	Standard controls

Step 3: Apply the Minimum Necessary Standard

Avoid endpoints that return an entire patient object by default. Use a server-side allowlist and return only the fields required for the request.

// BAD: Returns all patient data
app.get('/api/patients/:id', async (req, res) => {
  const patient = await db.patients.findById(req.params.id);
  res.json(patient);
});

// GOOD: Return only allowlisted fields
app.get('/api/patients/:id', async (req, res) => {
  const requestedFields = req.query.fields?.split(',') || ['id', 'name'];
  const allowedFields = ['id', 'name', 'dateOfBirth'];

  const fields = requestedFields.filter(field => allowedFields.includes(field));
  const patient = await db.patients.findById(req.params.id);

  const filtered = Object.fromEntries(
    Object.entries(patient).filter(([key]) => fields.includes(key))
  );

  res.json(filtered);
});

Do not let a client choose arbitrary database fields. Validate requested fields against an endpoint-specific allowlist.

Technical Safeguards Implementation

Access Control: Authentication

Use strong authentication for every user who can access PHI. This example verifies a password, verifies an MFA code, issues a short-lived JWT, and records the event.

const crypto = require('crypto');
const jwt = require('jsonwebtoken');
const bcrypt = require('bcrypt');

class HIPAAAuthService {
  async authenticate(username, password, mfaCode, requestContext) {
    // 1. Verify credentials
    const user = await this.getUserByUsername(username);
    if (!user) throw new Error('Invalid credentials');

    const validPassword = await bcrypt.compare(password, user.passwordHash);
    if (!validPassword) throw new Error('Invalid credentials');

    // 2. Verify MFA using TOTP
    const validMFA = this.verifyTOTP(user.mfaSecret, mfaCode);
    if (!validMFA) throw new Error('Invalid MFA code');

    // 3. Issue a short-lived token for PHI access
    const token = jwt.sign(
      {
        sub: user.id,
        role: user.role,
        mfa_verified: true
      },
      process.env.JWT_SECRET,
      { expiresIn: '15m' }
    );

    // 4. Record the authentication event
    await this.auditLog('AUTH_SUCCESS', {
      userId: user.id,
      ip: requestContext.ip
    });

    return { token, expiresIn: 900 };
  }

  verifyTOTP(secret, token) {
    const period = 30;
    const digits = 6;
    const now = Math.floor(Date.now() / 1000);
    const counter = Math.floor(now / period);

    const buffer = Buffer.alloc(8);
    buffer.writeUInt32BE(0, 0);
    buffer.writeUInt32BE(counter, 4);

    const hmac = crypto.createHmac('sha1', secret).update(buffer).digest();
    const offset = hmac[hmac.length - 1] & 0x0f;

    const code = (
      ((hmac[offset] & 0x7f) << 24) |
      ((hmac[offset + 1] & 0xff) << 16) |
      ((hmac[offset + 2] & 0xff) << 8) |
      (hmac[offset + 3] & 0xff)
    ) % Math.pow(10, digits);

    return code.toString().padStart(digits, '0') === token;
  }
}

Implementation checklist:

Require MFA for PHI-capable accounts.
Keep PHI access tokens short-lived.
Store signing keys securely.
Record successful and failed authentication attempts.
Add refresh-token rotation if your architecture uses refresh tokens.

Access Control: Authorization

Authentication identifies the caller. Authorization determines whether that caller can access a specific resource.

Start with role-based access control (RBAC):

const ROLES = {
  ADMIN: 'admin',
  PROVIDER: 'provider',
  NURSE: 'nurse',
  BILLING: 'billing',
  PATIENT: 'patient'
};

const PERMISSIONS = {
  [ROLES.ADMIN]: ['read:all', 'write:all', 'delete:all'],
  [ROLES.PROVIDER]: [
    'read:patients',
    'write:patients',
    'read:labs',
    'write:orders'
  ],
  [ROLES.NURSE]: ['read:patients', 'write:vitals', 'read:labs'],
  [ROLES.BILLING]: ['read:billing', 'read:patients:limited'],
  [ROLES.PATIENT]: ['read:self', 'write:self']
};

Enforce permissions with middleware:

const authorize = (...requiredPermissions) => {
  return async (req, res, next) => {
    const user = req.user;
    const userPermissions = PERMISSIONS[user.role] || [];

    const hasPermission = requiredPermissions.every(permission =>
      userPermissions.includes(permission)
    );

    if (!hasPermission) {
      await auditLog('AUTHZ_DENIED', {
        userId: user.id,
        action: req.method,
        path: req.path,
        required: requiredPermissions
      });

      return res.status(403).json({
        error: 'Insufficient permissions'
      });
    }

    next();
  };
};

Apply authentication and authorization before the route handler:

app.get(
  '/api/patients/:id/records',
  authenticate,
  authorize('read:patients'),
  getPatientRecords
);

RBAC alone is not enough for patient records. Also verify the provider-to-patient relationship or whether the patient owns the requested record.

Encryption in Transit

Require HTTPS for all API communication and configure TLS 1.3.

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('ca-cert.pem'),
  minVersion: 'TLSv1.3',
  ciphers: [
    'TLS_AES_256_GCM_SHA384',
    'TLS_CHACHA20_POLY1305_SHA256',
    'TLS_AES_128_GCM_SHA256'
  ].join(':'),
  honorCipherOrder: true
};

const server = https.createServer(options, app);

Redirect HTTP traffic to HTTPS:

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(`https://${req.headers.host}${req.url}`);
  }

  next();
});

Add HTTP Strict Transport Security (HSTS):

app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains; preload'
  );

  next();
});

Encryption at Rest

Encrypt stored PHI and manage encryption keys with a managed key service such as AWS KMS, GCP KMS, or Azure Key Vault.

The following example uses AES-256-GCM, which provides encryption and integrity protection:

const crypto = require('crypto');

class EncryptionService {
  constructor(key) {
    // In production, use a managed KMS or vault for key management.
    this.key = crypto.scryptSync(key, 'salt', 32);
    this.algorithm = 'aes-256-gcm';
  }

  encrypt(plaintext) {
    const iv = crypto.randomBytes(16);
    const cipher = crypto.createCipheriv(this.algorithm, this.key, iv);

    let encrypted = cipher.update(plaintext, 'utf8', 'hex');
    encrypted += cipher.final('hex');

    return {
      encryptedData: encrypted,
      iv: iv.toString('hex'),
      authTag: cipher.getAuthTag().toString('hex')
    };
  }

  decrypt(encryptedData, iv, authTag) {
    const decipher = crypto.createDecipheriv(
      this.algorithm,
      this.key,
      Buffer.from(iv, 'hex')
    );

    decipher.setAuthTag(Buffer.from(authTag, 'hex'));

    let decrypted = decipher.update(encryptedData, 'hex', 'utf8');
    decrypted += decipher.final('utf8');

    return decrypted;
  }
}

Encrypt PHI fields before persistence and decrypt only when an authorized request needs them:

class PatientRecord {
  constructor(db, encryptionService) {
    this.db = db;
    this.encryption = encryptionService;
  }

  async create(data) {
    const encryptedData = {
      ...data,
      ssn: this.encryption.encrypt(data.ssn),
      diagnosis: this.encryption.encrypt(data.diagnosis),
      treatmentNotes: this.encryption.encrypt(data.treatmentNotes)
    };

    await this.db.patients.insert(encryptedData);
    await auditLog('PHI_CREATED', { recordType: 'patient' });
  }

  async findById(id) {
    const record = await this.db.patients.findById(id);

    return {
      ...record,
      ssn: this.encryption.decrypt(
        record.ssn.encryptedData,
        record.ssn.iv,
        record.ssn.authTag
      ),
      diagnosis: this.encryption.decrypt(
        record.diagnosis.encryptedData,
        record.diagnosis.iv,
        record.diagnosis.authTag
      ),
      treatmentNotes: this.encryption.decrypt(
        record.treatmentNotes.encryptedData,
        record.treatmentNotes.iv,
        record.treatmentNotes.authTag
      )
    };
  }
}

Audit Controls Implementation

Comprehensive Audit Logging

Your API needs a record of who accessed PHI, what they did, when it occurred, and whether the action succeeded.

const winston = require('winston');

const auditLogger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [
    new winston.transports.File({
      filename: '/var/log/hipaa-audit/audit.log',
      maxsize: 52428800,
      maxFiles: 365
    }),
    new winston.transports.Http({
      host: 'siem.internal',
      path: '/api/logs',
      ssl: true
    })
  ]
});

Use a single audit-log function so every route produces consistent events:

const auditLog = async (event, details) => {
  const logEntry = {
    timestamp: new Date().toISOString(),
    event,
    actor: details.userId,
    action: details.action,
    resource: details.resource,
    outcome: details.outcome || 'SUCCESS',
    ipAddress: details.ip,
    userAgent: details.userAgent,
    details: details.metadata
  };

  auditLogger.info(logEntry);
  await db.auditLogs.insert(logEntry);
};

Add middleware that captures PHI-related endpoint activity:

app.use((req, res, next) => {
  const start = Date.now();

  res.on('finish', async () => {
    const duration = Date.now() - start;
    const isPHIEndpoint =
      req.path.includes('/patients') || req.path.includes('/records');

    if (!isPHIEndpoint) return;

    await auditLog('API_ACCESS', {
      userId: req.user?.id || 'anonymous',
      action: req.method,
      resource: req.path,
      outcome: res.statusCode < 400 ? 'SUCCESS' : 'FAILURE',
      ip: req.ip,
      userAgent: req.headers['user-agent'],
      metadata: {
        duration,
        statusCode: res.statusCode,
        queryParams: Object.keys(req.query)
      }
    });
  });

  next();
});

Avoid putting unnecessary PHI in logs. Log identifiers and event metadata needed for investigation, but do not log complete patient records, access tokens, passwords, or sensitive request bodies.

Required Audit Events

Event type	What to log	Retention
Authentication	Success/failure, MFA status, IP	6 years
Authorization	Denied access attempts	6 years
PHI access	Who accessed what and when	6 years
PHI modification	Before/after values	6 years
PHI deletion	What was deleted and by whom	6 years
System changes	Configuration changes, new users	6 years
Security events	Failed requests, rate limits	6 years

Audit Report Generation

Generate reports that compliance teams can review without manually querying raw logs.

const generateAuditReport = async (startDate, endDate, options = {}) => {
  const query = {
    timestamp: {
      $gte: new Date(startDate),
      $lte: new Date(endDate)
    }
  };

  if (options.userId) {
    query.actor = options.userId;
  }

  if (options.eventType) {
    query.event = options.eventType;
  }

  const logs = await db.auditLogs.find(query).sort({ timestamp: 1 });

  return {
    reportPeriod: { start: startDate, end: endDate },
    generatedAt: new Date().toISOString(),
    summary: {
      totalEvents: logs.length,
      uniqueUsers: new Set(logs.map(log => log.actor)).size,
      failures: logs.filter(log => log.outcome === 'FAILURE').length,
      phiAccess: logs.filter(log => log.event === 'PHI_ACCESS').length
    },
    events: logs
  };
};

Schedule weekly reporting:

cron.schedule('0 0 * * 1', async () => {
  const end = new Date();
  const start = new Date(end.getTime() - 7 * 24 * 60 * 60 * 1000);

  const report = await generateAuditReport(start, end);
  await sendToComplianceTeam(report);
});

API Security Best Practices

Input Validation

Validate every path parameter, query parameter, header, and request body field. Do not pass client input directly into database queries.

const {
  body,
  param,
  validationResult
} = require('express-validator');

const validatePatientRequest = [
  body('firstName')
    .trim()
    .notEmpty()
    .matches(/^[a-zA-Z\s'-]+$/)
    .withMessage('Invalid first name format')
    .isLength({ max: 50 }),

  body('dateOfBirth')
    .isISO8601()
    .withMessage('Invalid date format')
    .custom(value => new Date(value) < new Date())
    .withMessage('Date of birth must be in the past'),

  body('ssn')
    .optional()
    .matches(/^\d{3}-\d{2}-\d{4}$/)
    .withMessage('Invalid SSN format'),

  body('email')
    .optional()
    .isEmail()
    .normalizeEmail(),

  param('id')
    .isUUID()
    .withMessage('Invalid patient ID format'),

  (req, res, next) => {
    const errors = validationResult(req);

    if (!errors.isEmpty()) {
      return res.status(400).json({
        error: 'Validation failed',
        details: errors.array()
      });
    }

    next();
  }
];

Rate Limiting

Apply stricter limits to authentication endpoints and broader limits to general API routes.

const rateLimit = require('express-rate-limit');

const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  message: { error: 'Too many authentication attempts' },
  standardHeaders: true,
  legacyHeaders: false,
  handler: async (req, res) => {
    await auditLog('RATE_LIMIT_EXCEEDED', {
      userId: req.body.username,
      ip: req.ip,
      endpoint: 'auth'
    });

    res.status(429).json({ error: 'Too many attempts' });
  }
});

const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 100,
  message: { error: 'Rate limit exceeded' }
});

app.use('/api/auth', authLimiter);
app.use('/api', apiLimiter);

Error Handling

Return generic client errors and log diagnostic details internally. Never include PHI or implementation details in error responses.

app.use((err, req, res, next) => {
  console.error('Error:', {
    message: err.message,
    stack: err.stack,
    path: req.path,
    user: req.user?.id
  });

  res.status(err.status || 500).json({
    error: 'An error occurred processing your request',
    requestId: req.id
  });
});

Never expose the following in API errors:

Stack traces
Database schema details
Internal IP addresses
User counts
PHI
Access tokens or secrets

Common HIPAA API Violations and How to Avoid Them

Violation: Inadequate Access Controls

Scenario: Any authenticated user can retrieve any patient record.

// BAD: Authentication alone does not authorize access
app.get('/api/patients/:id', async (req, res) => {
  const patient = await db.patients.findById(req.params.id);
  res.json(patient);
});

Fix: Verify that the requester owns the record or has a documented provider relationship with the patient.

app.get('/api/patients/:id', async (req, res) => {
  const patient = await db.patients.findById(req.params.id);

  // Patient accesses their own record
  if (req.user.id === patient.userId) {
    return res.json(patient);
  }

  // Provider accesses an assigned patient's record
  const assignment = await db.providerAssignments.findOne({
    providerId: req.user.id,
    patientId: patient.id
  });

  if (assignment) {
    return res.json(patient);
  }

  await auditLog('UNAUTHORIZED_ACCESS_ATTEMPT', {
    userId: req.user.id,
    patientId: patient.id
  });

  res.status(403).json({ error: 'Access denied' });
});

Violation: Missing Audit Logs

Scenario: There is no record of who accessed patient data.

Fix: Record all PHI access, authorization failures, changes, deletions, and security events. Store logs in append-only storage and retain them for six years.

Violation: Unencrypted Data Transmission

Scenario: The API accepts plain HTTP connections.

Fix: Require HTTPS and add HSTS.

app.use((req, res, next) => {
  if (!req.secure && process.env.NODE_ENV === 'production') {
    return res.status(403).json({
      error: `HTTPS required. Connect via https://${req.headers.host}`
    });
  }

  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains'
  );

  next();
});

Violation: Excessive Data Exposure

Scenario: An endpoint returns a complete patient record when the client only needs a name.

Fix: Use field-level filtering and a safe projection.

app.get('/api/patients/:id', async (req, res) => {
  const fields = req.query.fields?.split(',') || ['id', 'name'];
  const projection = Object.fromEntries(fields.map(field => [field, 1]));

  const patient = await db.patients.findById(req.params.id, projection);
  res.json(patient);
});

In production, validate fields against an allowlist before building the projection.

Production Deployment Checklist

Before handling live PHI:

[ ] Execute BAAs with all vendors
[ ] Implement MFA for all users
[ ] Enable TLS 1.3 for all endpoints
[ ] Encrypt PHI at rest with AES-256
[ ] Implement comprehensive audit logging
[ ] Configure audit-log retention for 6+ years
[ ] Configure RBAC and resource-level authorization
[ ] Implement rate limiting
[ ] Create an incident-response plan
[ ] Document all security controls
[ ] Conduct a security risk assessment
[ ] Train staff on HIPAA requirements
[ ] Schedule regular security audits

HIPAA Security Risk Assessment Template

System Overview

System name: [API Name]
PHI types handled: [List]
Data flow: [Diagram]

Threat Assessment

Threat	Likelihood	Impact	Mitigation
Unauthorized access	Medium	High	MFA, RBAC
Data breach	Low	Critical	Encryption
Insider threat	Medium	High	Audit logs

Control Testing

[ ] Authentication bypass test
[ ] Authorization bypass test
[ ] SQL injection test
[ ] XSS test
[ ] Encryption verification

Sign-off

Security Officer: _______________  Date: _______
CTO:              _______________  Date: _______

Real-World Use Cases

Telemedicine Platform API

A telehealth startup builds HIPAA-compliant video consultations.

Challenge: Secure transmission of patient-provider video calls
Solution: End-to-end encrypted WebRTC with a HIPAA-compliant signaling API
Result: SOC 2 Type II certified, 500K+ consultations without breach

Key implementation details:

JWT authentication with MFA
Ephemeral room tokens that expire after a consultation
No PHI stored in logs
BAA with Twilio for video infrastructure

Patient Portal API

A hospital system modernizes patient access.

Challenge: More than 20 legacy systems with inconsistent security
Solution: A unified API gateway with centralized authentication and auditing
Result: A single source of truth and simplified compliance reporting

Key implementation details:

OAuth 2.0 with SMART on FHIR
Centralized audit logging
Field-level access control
Automated breach detection

Health Data Integration Platform

A health technology company aggregates data from multiple EHRs.

Challenge: Different security models across EHR vendors
Solution: An abstraction layer with uniform HIPAA controls
Result: More than 100 hospital integrations and zero compliance findings

Key implementation details:

Data normalization with consistent encryption
Per-tenant audit trails
Automated BAA tracking
Real-time compliance dashboards

Conclusion

HIPAA compliance for APIs requires deliberate architecture decisions around authentication, encryption, authorization, and audit logging.

Use this implementation checklist as your baseline:

Execute BAAs with all vendors before handling PHI.
Require MFA and implement role-based access control.
Verify resource-level authorization for every PHI request.
Encrypt data in transit with TLS 1.3 and at rest with AES-256.
Log PHI access and retain audit records for six years.
Apply the minimum necessary standard to every endpoint.
Use Apidog to streamline API documentation and compliance workflows.

FAQ

What makes an API HIPAA-compliant?

An API is HIPAA-compliant when it implements the technical safeguards required to protect ePHI, including encryption, access controls, and audit logging. It must also support required administrative safeguards such as policies, staff training, and BAAs, plus applicable physical safeguards.

Do I need a BAA for my API?

Yes. If your API handles, processes, or stores PHI on behalf of a covered entity, you are a Business Associate and must sign a BAA. This also applies to cloud providers, API services, and subprocessors that handle PHI.

What encryption is required for HIPAA?

HIPAA requires encryption in transit and at rest. Use TLS 1.3 for API communication and AES-256 for stored data. Although encryption is technically addressable in the Security Rule, it is effectively required for compliance.

How long must HIPAA audit logs be retained?

HIPAA requires audit logs to be retained for six years from the date they were created or when the record was last in effect, whichever is later.

Can I use JWT for HIPAA-compliant authentication?

Yes. JWTs can be used when implemented securely: use short expiration periods, secure token storage, and refresh-token rotation. Combine JWT-based authentication with MFA for production systems that access PHI.

What is the minimum necessary standard?

The minimum necessary standard requires an API to expose only the PHI required for the intended purpose. Implement field-level filtering and purpose-based access controls to enforce it.

Do audit logs need to be encrypted?

Yes. Audit logs containing PHI should be encrypted at rest. Store them in append-only storage to help prevent tampering.

How do I handle breach notification?

If unauthorized PHI access occurs:

Contain the breach.
Assess risk using the four-factor test.
Notify affected individuals within 60 days.
Notify HHS immediately for breaches affecting 500 or more individuals.
Document the incident, assessment, and mitigation steps.

Can I use cloud services for HIPAA workloads?

Yes, if the provider signs a BAA. AWS, GCP, and Azure offer HIPAA-eligible services. Configure each service according to the provider's HIPAA implementation guidance.

What penalties exist for HIPAA violations?

Civil penalties range from $100 to $50,000 per violation, with annual maximums of $1.5 million per violation category. Criminal penalties can include fines up to $250,000 and imprisonment for up to 10 years.

How to Use Make (Integromat) API ?

Preecha — Mon, 13 Jul 2026 01:02:11 +0000

TL;DR

The Make (formerly Integromat) API lets you automate workflows, manage scenarios, trigger executions, configure webhooks, and manage teams programmatically. It supports API key and OAuth 2.0 authentication, uses REST endpoints for scenarios, executions, webhooks, and organizations, and applies plan-based rate limits of 60–600 requests per minute.

Try Apidog today

Introduction

Make processes over 2 billion operations monthly for more than 1 million users across 100+ countries. If you are building automation tooling, managing client workflows, or integrating across Make's 1000+ apps, the API is the control plane for scalable automation.

For example, an agency managing 50+ client automations can use the API to automate scenario deployments, execution monitoring, error handling, and client reporting instead of updating each workflow manually.

This guide covers:

API key and OAuth 2.0 authentication
Scenario CRUD operations
Manual scenario execution and monitoring
Webhook management
Team management
Rate-limit handling
Production deployment practices

💡 Apidog simplifies API integration testing. Use it to test Make endpoints, validate OAuth flows, inspect execution responses, mock responses, and share test scenarios with your team.

What Is the Make API?

Make provides a RESTful API for managing automation workflows programmatically.

You can use it to:

Create, update, and delete scenarios
Trigger scenarios manually
Read execution history and execution details
Create and manage webhooks
Manage organization users and roles
Manage connections, apps, organization settings, and workspaces

Key features

Feature	Description
RESTful API	JSON-based endpoints
OAuth 2.0 + API keys	Flexible authentication options
Webhooks	Real-time execution notifications
Rate limiting	60–600 requests/minute, depending on plan
Scenario management	Full CRUD operations
Execution control	Start, stop, and monitor runs
Team API	User and permission management

Make plans and API access

Plan	API access	Rate limit	Best for
Free	Limited	60/min	Testing and learning
Core	Full API	120/min	Small businesses
Pro	Full API + priority	300/min	Growing teams
Teams	Full API + admin	600/min	Agencies and enterprises
Enterprise	Custom limits	Custom	Large organizations

API base URL

https://api.make.com/api/v2/

API versions

Version	Status	Use case
v2	Current	New integrations
v1	Deprecated	Legacy integrations; migrate when possible

Getting Started: Authentication Setup

1. Create Make API credentials

Sign in to Make.
Go to Settings > Developer settings.
Generate API credentials.
Store secrets outside source control.

2. Choose an authentication method

Method	Best for	Security model
API key	Internal scripts and single-organization integrations	Secure secret storage required
OAuth 2.0	Multi-tenant apps and client integrations	User-scoped tokens

3. Configure an API key

Use an API key for internal services.

# .env
MAKE_API_KEY="your_api_key_here"
MAKE_ORGANIZATION_ID="your_org_id"

Do not commit this file. Load secrets through your deployment platform or a secret manager.

4. Configure OAuth 2.0

Use OAuth when your application connects to multiple customer Make accounts.

Go to Settings > Developer settings > OAuth apps.
Create an OAuth application.
Configure the redirect URI.
Save the client ID and client secret.

const MAKE_CLIENT_ID = process.env.MAKE_CLIENT_ID;
const MAKE_CLIENT_SECRET = process.env.MAKE_CLIENT_SECRET;
const MAKE_REDIRECT_URI = process.env.MAKE_REDIRECT_URI;

function getAuthUrl(state) {
  const params = new URLSearchParams({
    client_id: MAKE_CLIENT_ID,
    redirect_uri: MAKE_REDIRECT_URI,
    scope: "read write execute",
    state,
    response_type: "code",
  });

  return `https://www.make.com/oauth/authorize?${params.toString()}`;
}

Use a cryptographically secure, short-lived state value and validate it in the callback before exchanging the authorization code.

5. Exchange the authorization code for tokens

async function exchangeCodeForToken(code) {
  const response = await fetch("https://www.make.com/oauth/token", {
    method: "POST",
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
    },
    body: new URLSearchParams({
      grant_type: "authorization_code",
      client_id: MAKE_CLIENT_ID,
      client_secret: MAKE_CLIENT_SECRET,
      redirect_uri: MAKE_REDIRECT_URI,
      code,
    }),
  });

  if (!response.ok) {
    throw new Error(`Token exchange failed: ${response.status}`);
  }

  const data = await response.json();

  return {
    accessToken: data.access_token,
    refreshToken: data.refresh_token,
    expiresIn: data.expires_in,
  };
}

app.get("/oauth/callback", async (req, res) => {
  const { code, state } = req.query;

  try {
    // Validate state before continuing.
    const tokens = await exchangeCodeForToken(code);

    await db.integrations.create({
      userId: req.session.userId,
      accessToken: tokens.accessToken,
      refreshToken: tokens.refreshToken,
      tokenExpiry: Date.now() + tokens.expiresIn * 1000,
    });

    res.redirect("/success");
  } catch (error) {
    console.error("OAuth error:", error);
    res.status(500).send("Authentication failed");
  }
});

6. Create a reusable API client

Centralize authentication and error handling so every endpoint behaves consistently.

const MAKE_BASE_URL = "https://api.make.com/api/v2";

async function makeRequest(endpoint, options = {}) {
  const token = options.useOAuth
    ? await getOAuthToken()
    : process.env.MAKE_API_KEY;

  const response = await fetch(`${MAKE_BASE_URL}${endpoint}`, {
    ...options,
    headers: {
      Authorization: `Token ${token}`,
      "Content-Type": "application/json",
      ...options.headers,
    },
  });

  if (!response.ok) {
    let details = {};

    try {
      details = await response.json();
    } catch {
      // Keep the HTTP status when the response has no JSON body.
    }

    const error = new Error(
      `Make API error (${response.status}): ${details.message || "Request failed"}`
    );
    error.status = response.status;
    error.rateLimit = {
      limit: response.headers.get("X-RateLimit-Limit"),
      remaining: response.headers.get("X-RateLimit-Remaining"),
      reset: response.headers.get("X-RateLimit-Reset"),
    };

    throw error;
  }

  if (response.status === 204) {
    return null;
  }

  return response.json();
}

// Example
const scenarios = await makeRequest("/scenarios");
console.log(`Found ${scenarios.data.length} scenarios`);

Scenario Management

List scenarios

Use pagination from the beginning. Do not assume every scenario fits in one response.

async function listScenarios(filters = {}) {
  const params = new URLSearchParams({
    limit: String(filters.limit || 50),
    offset: String(filters.offset || 0),
  });

  if (filters.folder) {
    params.set("folder", filters.folder);
  }

  return makeRequest(`/scenarios?${params.toString()}`);
}

const scenarios = await listScenarios({ limit: 100 });

scenarios.data.forEach((scenario) => {
  console.log(`${scenario.name} — ${scenario.active ? "Active" : "Paused"}`);
  console.log(`  Last run: ${scenario.lastRunDate || "Never"}`);
});

Get scenario details

Fetch the scenario before updating it when you need to inspect its current configuration.

async function getScenario(scenarioId) {
  return makeRequest(`/scenarios/${scenarioId}`);
}

const scenario = await getScenario("12345");

console.log(`Name: ${scenario.name}`);
console.log(`Modules: ${scenario.modules.length}`);
console.log(`Schedule: ${scenario.schedule?.cronExpression || "Manual"}`);

Create a scenario

Create scenarios from a known blueprint, such as a blueprint exported from the Make editor.

async function createScenario(scenarioData) {
  return makeRequest("/scenarios", {
    method: "POST",
    body: JSON.stringify({
      name: scenarioData.name,
      blueprint: scenarioData.blueprint,
      active: scenarioData.active || false,
      priority: scenarioData.priority || 1,
      maxErrors: scenarioData.maxErrors || 3,
      autoCommit: scenarioData.autoCommit || true,
      description: scenarioData.description || "",
    }),
  });
}

const newScenario = await createScenario({
  name: "Lead Sync to CRM",
  blueprint: {
    modules: [
      {
        id: 1,
        app: "webhooks",
        action: "customWebhook",
        parameters: {},
      },
      {
        id: 2,
        app: "salesforce",
        action: "createRecord",
        parameters: {},
      },
    ],
    connections: [{ from: 1, to: 2 }],
  },
  active: true,
  description: "Sync webhook leads to Salesforce",
});

console.log(`Scenario created: ${newScenario.id}`);

Update a scenario

Use PATCH for targeted changes, such as pausing a scenario or changing its schedule.

async function updateScenario(scenarioId, updates) {
  return makeRequest(`/scenarios/${scenarioId}`, {
    method: "PATCH",
    body: JSON.stringify(updates),
  });
}

// Pause a scenario.
await updateScenario("12345", { active: false });

// Run every six hours.
await updateScenario("12345", {
  schedule: {
    cronExpression: "0 */6 * * *",
    timezone: "America/New_York",
  },
});

Delete a scenario

Use deletion carefully. Export or back up critical scenario definitions first.

async function deleteScenario(scenarioId) {
  await makeRequest(`/scenarios/${scenarioId}`, {
    method: "DELETE",
  });

  console.log(`Scenario ${scenarioId} deleted`);
}

Execution Management

Trigger a scenario manually

Use manual execution when an external system needs to invoke a scenario or when you need to re-run a workflow from an application.

async function executeScenario(scenarioId, inputData = null) {
  return makeRequest(`/scenarios/${scenarioId}/execute`, {
    method: "POST",
    body: inputData ? JSON.stringify(inputData) : undefined,
  });
}

// Run without input.
const execution = await executeScenario("12345");
console.log(`Execution started: ${execution.id}`);

// Run with input.
const executionWithData = await executeScenario("12345", {
  lead: {
    email: "prospect@example.com",
    name: "John Doe",
    company: "Acme Corp",
  },
});

Read execution history

Filter by status and time range to build monitoring jobs that focus on failures.

async function getExecutionHistory(scenarioId, filters = {}) {
  const params = new URLSearchParams({
    limit: String(filters.limit || 50),
  });

  if (filters.from) params.set("from", filters.from);
  if (filters.to) params.set("to", filters.to);
  if (filters.status) params.set("status", filters.status);

  return makeRequest(
    `/scenarios/${scenarioId}/executions?${params.toString()}`
  );
}

const failedExecutions = await getExecutionHistory("12345", {
  from: new Date(Date.now() - 86_400_000).toISOString(),
  status: "error",
  limit: 100,
});

failedExecutions.data.forEach((execution) => {
  console.log(`Execution ${execution.id}: ${execution.error?.message}`);
});

Get execution details

async function getExecution(executionId) {
  return makeRequest(`/executions/${executionId}`);
}

const execution = await getExecution("98765");

console.log(`Status: ${execution.status}`);
console.log(`Duration: ${execution.duration}ms`);
console.log(`Modules executed: ${execution.modulesExecuted}`);

Stop a running execution

async function stopExecution(executionId) {
  await makeRequest(`/executions/${executionId}`, {
    method: "DELETE",
  });

  console.log(`Execution ${executionId} stopped`);
}

Webhook Management

Create a webhook

Create a webhook and attach it to a scenario that should process incoming events.

async function createWebhook(webhookData) {
  return makeRequest("/webhooks", {
    method: "POST",
    body: JSON.stringify({
      name: webhookData.name,
      scenarioId: webhookData.scenarioId,
      type: "custom",
      hookType: "HEAD",
      security: {
        type: "none",
      },
    }),
  });
}

const webhook = await createWebhook({
  name: "Lead Capture Webhook",
  scenarioId: "12345",
  type: "custom",
  hookType: "HEAD",
  security: { type: "none" },
});

console.log(`Webhook URL: ${webhook.url}`);

List webhooks

async function listWebhooks() {
  return makeRequest("/webhooks");
}

const webhooks = await listWebhooks();

webhooks.data.forEach((webhook) => {
  console.log(`${webhook.name}: ${webhook.url}`);
});

Delete a webhook

async function deleteWebhook(webhookId) {
  await makeRequest(`/webhooks/${webhookId}`, {
    method: "DELETE",
  });

  console.log(`Webhook ${webhookId} deleted`);
}

Team and User Management

List organization users

async function listTeamMembers(organizationId) {
  return makeRequest(`/organizations/${organizationId}/users`);
}

const members = await listTeamMembers("org-123");

members.data.forEach((member) => {
  console.log(`${member.email} — ${member.role}`);
});

Invite a team member

async function addTeamMember(organizationId, email, role) {
  return makeRequest(`/organizations/${organizationId}/users`, {
    method: "POST",
    body: JSON.stringify({
      email,
      role,
    }),
  });
}

await addTeamMember("org-123", "newuser@example.com", "builder");

Update a user role

async function updateUserRole(organizationId, userId, newRole) {
  await makeRequest(`/organizations/${organizationId}/users/${userId}`, {
    method: "PATCH",
    body: JSON.stringify({ role: newRole }),
  });

  console.log(`User ${userId} role updated to ${newRole}`);
}

User roles

Role	Permissions
Viewer	View scenarios, no edits
Builder	Create and edit scenarios
Manager	Manage team and billing
Admin	Full organization access

Rate Limiting

Understand plan limits

Plan	Requests/minute	Burst limit
Free	60	100
Core	120	200
Pro	300	500
Teams	600	1000
Enterprise	Custom	Custom

Inspect rate-limit headers

Header	Description
`X-RateLimit-Limit`	Maximum requests per minute
`X-RateLimit-Remaining`	Remaining requests
`X-RateLimit-Reset`	Seconds until reset

Retry rate-limited requests

Retry 429 responses with exponential backoff. Keep retries bounded so a failing upstream service does not create an unbounded queue.

async function makeRateLimitedRequest(
  endpoint,
  options = {},
  maxRetries = 3
) {
  for (let attempt = 1; attempt <= maxRetries; attempt += 1) {
    try {
      return await makeRequest(endpoint, options);
    } catch (error) {
      const canRetry = error.status === 429 && attempt < maxRetries;

      if (!canRetry) {
        throw error;
      }

      const delay = 2 ** attempt * 1000;

      console.warn(
        `Rate limited. Retrying in ${delay}ms. ` +
        `Remaining: ${error.rateLimit?.remaining ?? "unknown"}`
      );

      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }
}

For high-volume workloads, add request queuing and throttle calls before you reach the limit.

Production Deployment Checklist

Before going live:

[ ] Use API keys for internal integrations and OAuth 2.0 for client integrations
[ ] Store credentials in an encrypted database or secret manager
[ ] Implement rate limiting and request queuing
[ ] Monitor scenario executions and configure alerts
[ ] Configure error notifications through email or Slack
[ ] Add retry logic for failed executions
[ ] Log API requests, responses, and execution identifiers
[ ] Export or back up critical scenarios before major changes

Real-World Use Cases

Agency client management

A marketing agency managing 100+ client automations can build a central dashboard on top of the Make API.

Challenge: Manual scenario updates across client accounts.

Implementation:

Connect each client account through OAuth
Deploy scenario blueprints in bulk
Poll execution history for failed runs
Generate client usage reports

Result: More consistent deployments and less time spent on repetitive administration.

E-commerce order processing

An online store can use a webhook-triggered scenario to automate order fulfillment.

Challenge: Manual order entry into a warehouse system.

Implementation:

Receive an order event through a Shopify webhook.
Trigger a Make scenario.
Process the order and update the warehouse system.
Monitor failed executions and retry when appropriate.

Result: Reduced manual entry and more reliable order processing.

Conclusion

The Make API provides the building blocks for managing workflow automation from your own application or internal tooling.

Key implementation takeaways:

Use API keys for internal services and OAuth 2.0 for multi-tenant applications.
Use scenario endpoints for workflow CRUD operations.
Trigger and monitor executions to build operational visibility.
Manage webhooks and organization users through the API.
Design around plan-based rate limits of 60–600 requests per minute.
Test authentication flows, payloads, and error responses before production deployment.

FAQ

How do I authenticate with the Make API?

Use an API key from Developer settings for internal integrations. Use OAuth 2.0 when users connect their own Make accounts to your application.

Can I trigger scenarios programmatically?

Yes. Use the /scenarios/{id}/execute endpoint to trigger a scenario, optionally with input data.

What are Make rate limits?

Rate limits range from 60 requests per minute on the Free plan to 600 requests per minute on the Teams plan. Enterprise limits are custom.

How do I get execution logs?

Use /scenarios/{id}/executions to retrieve execution history and filter it by date range or status.

Can I create webhooks via the API?

Yes. Use the /webhooks endpoint to create, list, and delete webhooks associated with scenarios.

10 Best Bank API Management Platforms for Secure Fintech APIs

Preecha — Sun, 12 Jul 2026 13:01:29 +0000

In today’s digital-first financial landscape, bank API management platforms sit at the center of innovation, security, and scalability. Banks use them to expose, control, and monitor APIs for fintech partners, regulatory compliance, and digital transformation.

Try Apidog today

What Are Bank API Management Platforms?

Bank API management platforms help banks design, secure, publish, monitor, and govern APIs. They address financial-industry requirements including regulatory compliance (such as PSD2 and Open Banking), data privacy, security, and high transaction volumes.

A bank API platform should enable teams to:

Safely expose services such as account data, payments, and identity verification to approved third parties.
Enforce authentication, authorization, consent, rate limits, and audit requirements.
Monitor API availability, latency, errors, security events, and business usage.
Manage API versions from design through deprecation.

Without robust API management, banks increase the risk of security breaches, compliance failures, unreliable integrations, and slow delivery.

Why Platform Selection Matters

Choose a platform based on the controls your APIs need in production:

Regulatory compliance: Support consent management, audit trails, data protection, and reporting for regulations such as PSD2, GDPR, and Open Banking.
Security: Use standards such as OAuth 2.0 and OpenID Connect, plus rate limiting and threat detection.
Scalability: Validate that the platform can support high transaction volumes without downtime.
Developer experience: Provide interactive documentation, testing tools, sandbox access, and a predictable onboarding flow for fintech partners.
Analytics: Track operational metrics and business KPIs in real time.

Key Features to Evaluate

Use this checklist when evaluating bank API management platforms.

API gateway
- Routes API traffic.
- Enforces authentication, authorization, quotas, and traffic policies.
Security controls
- Supports industry-standard authentication and encryption.
- Provides rate limiting and DDoS protection.
API lifecycle management
- Supports API design, deployment, versioning, publishing, and retirement.
Developer portal
- Offers self-service access to documentation, code samples, and sandbox environments.
Monitoring and analytics
- Tracks traffic, latency, errors, API adoption, and compliance-related events.
Compliance and consent management
- Records consent, data access, and audit events required for regulatory workflows.
Integration capabilities
- Connects with core banking systems, identity providers, and external fintech partners.

Top 10 Bank API Management Platforms (2026 Edition)

1. Apidog

Apidog is a spec-driven API platform focused on API design, testing, and documentation. It supports collaborative API lifecycle workflows and import/export capabilities for formats and tools such as Postman and Swagger.

Use it when your team needs to prototype, document, test, and mock banking APIs before implementation or partner onboarding.

2. MuleSoft Anypoint Platform

MuleSoft provides API lifecycle management, security controls, reusable assets, and deep integration capabilities. It is suited to complex banking environments with many systems to connect.

3. IBM API Connect

IBM API Connect targets high-security environments and provides governance, consent management, and hybrid deployment capabilities. It is relevant for banks that must integrate legacy systems.

4. Microsoft Azure API Management

Azure API Management provides scalability, hybrid cloud support, Microsoft ecosystem integration, developer portal functionality, and analytics.

5. Kong Konnect

Kong Konnect is a flexible, cloud-native platform with security features and real-time analytics. It is commonly considered for microservice architectures and API-first banking strategies.

6. WSO2 API Manager

WSO2 API Manager is an open-source option with support for open banking protocols. It is useful for banks that prioritize customization and cost control.

7. Tyk

Tyk provides a lightweight, open-source API gateway focused on security, analytics, and extensibility. It is an option for digital banks and fintech teams.

8. Axway Amplify

Axway Amplify offers hybrid deployment options, API security controls, and open banking accelerators.

9. SAP Integration Suite

SAP Integration Suite is tailored to organizations using SAP core systems and combines API management, integration, and analytics.

10. Apigee (by Google Cloud)

Apigee provides an API gateway, security controls, analytics, and compliance features. It is used by Tier-1 banks and is a common option for open banking initiatives.

Comparison Table

Platform	Security	Compliance	Analytics	Developer Portal	Deployment
Apidog	★★★★★	★★★★★	★★★★★	★★★★☆	Cloud / On-prem
MuleSoft	★★★★★	★★★★☆	★★★★★	★★★★★	Cloud / On-prem
IBM API Connect	★★★★★	★★★★★	★★★★☆	★★★★☆	Cloud / On-prem
Azure API Management	★★★★☆	★★★★☆	★★★★★	★★★★★	Cloud / Hybrid
Kong Konnect	★★★★☆	★★★★☆	★★★★☆	★★★★☆	Cloud / Hybrid
WSO2 API Manager	★★★★☆	★★★★☆	★★★★☆	★★★★☆	Cloud / On-prem
Tyk	★★★★☆	★★★★☆	★★★★☆	★★★☆☆	Cloud / On-prem
Axway Amplify	★★★★☆	★★★★★	★★★★☆	★★★★☆	Cloud / Hybrid
SAP Integration Suite	★★★★☆	★★★★☆	★★★★☆	★★★★☆	Cloud / On-prem
Apigee	★★★★☆	★★★☆☆	★★★★☆	★★★★★	Cloud / Hybrid

How to Choose a Platform

Use your architecture and regulatory requirements to narrow the list.

1. Map compliance requirements

Document the regulations and controls that apply to each API:

Open Banking or PSD2 requirements
Consent capture and revocation
Audit logging and retention
Personally identifiable information handling
Third-party provider access policies

Prioritize platforms that support the controls required in your jurisdiction.

2. Assess integration complexity

Inventory the systems your APIs must connect to:

Core banking platforms
Identity providers
Payment systems
CRM and fraud systems
Legacy databases and services

For legacy-heavy environments, platforms such as IBM API Connect or MuleSoft may be appropriate because of their integration capabilities.

3. Test the developer workflow

Have internal and external developers complete a basic integration:

Find the API in the developer portal.
Register an application.
Obtain credentials.
Call a sandbox endpoint.
Inspect an error response.
Move from sandbox to production access.

Apidog and Azure API Management emphasize interactive documentation and developer portal workflows.

4. Choose the deployment model

Select cloud, on-premises, or hybrid deployment based on internal policy, data residency, and operational requirements.

5. Estimate operational ownership

Open-source options such as WSO2 and Tyk may reduce licensing costs, but they require in-house expertise for deployment, security configuration, upgrades, and operations.

Practical Examples

Example 1: Open Banking Compliance

A European bank adopted Apigee to meet PSD2 requirements. The bank used consent management tools, a secure API gateway, and real-time analytics to expose account and payment APIs to authorized third-party providers.

A practical implementation flow looks like this:

Register and validate third-party providers.
Require OAuth 2.0 authorization for protected resources.
Record user consent before granting account access.
Apply scopes such as accounts.read and payments.initiate.
Log access and consent events for auditing.
Monitor failures, latency, and suspicious traffic.

Example 2: Accelerating Fintech Innovation

A digital-first bank used Apidog to prototype, document, and test APIs for mobile banking features. Mock data and collaborative API design allowed teams to validate contracts before backend implementation, reduce integration errors, and streamline developer onboarding.

A useful workflow is:

Define the API contract in OpenAPI.
Review endpoint names, request schemas, responses, and security scopes with backend and compliance teams.
Create mock responses for mobile and partner teams.
Run automated API tests against staging.
Publish updated documentation when the API version is released.

Example 3: Legacy System Integration

A multinational bank used MuleSoft to connect legacy core systems to modern mobile and web applications through APIs. Security, analytics, and lifecycle management supported the bank’s digital transformation.

In this pattern, the API layer separates consumer-facing contracts from older backend interfaces:

Mobile app / Web app / Fintech partner
                  |
             API gateway
                  |
        Integration and transformation
                  |
          Legacy core banking system

This approach lets teams evolve consumer APIs without directly exposing legacy system interfaces.

Code Example: Secure Account Balance Endpoint

Define security requirements in the API specification before implementation. The following simplified OpenAPI example requires an OAuth 2.0 token with the accounts.read scope.

paths:
  /accounts/{accountId}/balance:
    get:
      summary: Get account balance
      security:
        - OAuth2:
            - accounts.read
      parameters:
        - name: accountId
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Account balance
          content:
            application/json:
              schema:
                type: object
                properties:
                  balance:
                    type: number
                    format: float
                    example: 1234.56

Before publishing an endpoint like this, validate these implementation details:

Require OAuth 2.0 access tokens at the gateway.
Enforce the accounts.read scope.
Confirm that the authenticated user is authorized to access the requested accountId.
Apply rate limits to protect downstream banking systems.
Log access events without exposing sensitive data.
Test successful, unauthorized, forbidden, invalid-account, and rate-limited responses.

Platforms such as Apidog allow teams to import, test, document, and mock endpoints collaboratively before production rollout.

Why Apidog Is a Strong Choice for Bank API Management

Apidog is a strong option for banks that need a modern workflow for API design, testing, and documentation.

Spec-driven design: Create and manage OpenAPI and Swagger-based APIs for consistent contracts.
Collaboration: Support team collaboration, change tracking, and documentation generation for internal and external stakeholders.
Testing and mocking: Test and mock APIs before production to reduce integration errors when handling sensitive banking data.

For banks prioritizing API quality, collaborative design, testing, and documentation, Apidog is a compelling option.

Conclusion

Choosing a bank API management platform is a foundational step for modernizing banking services, meeting regulatory requirements, and enabling secure digital innovation.

Start with compliance obligations, integration architecture, deployment constraints, and developer workflows. Then evaluate platforms such as Apidog, Apigee, MuleSoft, and others against those requirements.

Banking is API-driven. Build the foundation with security, compliance, observability, and a developer experience that makes integrations easier to deliver and operate.

Unified API Platforms: Complete Guide & Best Practices

Preecha — Sun, 12 Jul 2026 01:01:38 +0000

In today's hyperconnected software landscape, teams often need to integrate with many third-party services. A unified API platform provides a single, standardized interface for accessing external APIs in one category—such as CRM, HRIS, accounting, or crypto data—without building a separate integration for every provider.

Try Apidog today

A unified API platform abstracts provider-specific authentication, endpoints, field names, and data models. Instead of maintaining dozens of integrations, your application connects once to a normalized API. This can reduce integration maintenance, speed up delivery, and give users a more consistent connection experience.

How Unified API Platforms Work

A unified API platform acts as middleware between your application and provider APIs.

Typical components include:

Standardized endpoints: Common resources such as GET /contacts or POST /companies are exposed across a software category.
Normalization layer: Requests and responses are translated between a universal data model and each provider's schema.
Connector logic: Per-provider connectors handle pagination, batching, rate limits, and provider-specific errors.
Authentication management: The platform manages OAuth, API keys, and custom token flows behind a consistent connection process.
Real-time or cached data: Depending on the platform, data may be fetched live or synchronized periodically for faster reads.

Request Flow

A typical contact-creation request might look like this:

POST /contacts
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com",
  "company": "Acme Corp"
}

The unified platform then:

Identifies the connected provider, such as Salesforce, HubSpot, or Pipedrive.
Maps the normalized fields to that provider's expected payload.
Applies the provider's authentication method.
Sends the request to the provider API.
Normalizes the provider response before returning it to your application.

Unified API Platforms vs. Direct Integrations

Area	Traditional integrations	Unified API platforms
Integration method	Custom code for each API	One connection for multiple providers
Maintenance overhead	High; maintained per provider	Lower; connectors are managed by the platform
Time to market	Slower	Faster
Data model	Provider-specific and inconsistent	Unified and normalized
Scaling provider coverage	More difficult as APIs grow	Easier to add supported providers

Why Use a Unified API Platform?

1. Accelerate Your Integration Roadmap

Integrate once to add support for multiple services in a category. This can help teams ship integration coverage sooner without implementing every provider from scratch.

2. Reduce Maintenance Work

Direct integrations require ongoing work when providers change authentication flows, endpoints, rate limits, or schemas. A unified platform centralizes much of that connector maintenance.

3. Keep a Consistent Developer Experience

Your application can use the same authentication, CRUD, sync, and error-handling patterns across providers instead of branching heavily for each one.

4. Improve Reliability and Security Controls

Unified platforms can centralize retries, error handling, credential storage, and permission handling. Your implementation still needs to validate permissions, handle failures, and protect user data appropriately.

5. Deliver Better User Workflows

Users can connect the systems they already use while your product exposes a consistent workflow for syncing data, triggering automations, and reducing manual entry.

Core Features to Look For

Data Model Normalization

Providers frequently use different schemas for the same business concept. For example, Salesforce, HubSpot, and Pipedrive all represent contacts differently.

A unified API maps these records to a shared model so your application can work with one shape:

{
  "id": "contact_123",
  "name": "Jane Doe",
  "email": "jane@example.com",
  "company": "Acme Corp"
}

Before adopting a platform, inspect its normalized fields carefully. A shallow model may work for basic CRUD but may not support provider-specific workflows.

Authentication Abstraction

A provider may use OAuth, API keys, or custom tokens. Unified platforms can provide one connection pattern while managing provider-specific credential and refresh behavior.

Your application should still define:

Who can create or revoke a connection
Which scopes are required
How connection failures are surfaced to users
How your backend associates a connection with a tenant or workspace

Webhooks and Event Handling

Webhook support enables event-driven syncs and automations. For example, a provider event can trigger a workflow when a contact changes.

When implementing webhooks:

Verify signatures where supported.
Make handlers idempotent.
Return quickly and process long-running work asynchronously.
Handle duplicate and out-of-order events.
Monitor failed deliveries and replay behavior.

Custom Field Mapping

Standard fields do not cover every use case. Custom mapping support is useful when users need to map fields such as customer_tier, territory, or provider-specific metadata.

A practical pattern is to keep normalized fields separate from provider-specific extensions:

{
  "name": "Jane Doe",
  "email": "jane@example.com",
  "custom_fields": {
    "customer_tier": "enterprise"
  }
}

Error Handling and Monitoring

A unified endpoint does not eliminate provider failures. Build for rate limits, expired credentials, validation errors, and temporary outages.

At minimum, log:

Connection and provider identifiers
Request IDs
HTTP status codes
Retry attempts
Provider error payloads, with secrets removed
Sync timestamps and cursor state

When to Use a Unified API Platform

Unified APIs are a strong fit when:

You need to support many similar integrations, such as multiple CRMs, HR systems, or email providers.
Your product becomes more valuable as integration coverage expands.
Engineering resources are limited.
A consistent data model and developer experience matter.
You need to launch broad provider coverage quickly.

A direct integration can still be the better choice when you need deep, specialized functionality for one provider that a normalized model cannot represent.

Common Use Cases

SaaS Integration Libraries

A SaaS product that connects to calendars, CRMs, or HRIS systems can use a unified API to support many providers without maintaining a separate connector for each one.

AI Agents and Automation Tools

AI agents and workflow automation products often need access to multiple external systems. A unified API can provide a scalable layer for authentication, normalized records, and event triggers.

Fintech and HR Tech

Financial and HR products may need to aggregate data from banking, payroll, or benefits providers. A unified model can simplify downstream reporting and application logic.

Enterprise Integration Hubs

Organizations with large technology stacks can use unified APIs as an integration layer to reduce custom point-to-point development.

Practical Example: Sync Contacts Across Multiple CRMs

Assume your product needs to sync contacts with Salesforce, HubSpot, and Pipedrive.

Direct Integration Approach

Without a unified platform, you need to:

Build and test a connector for each CRM.
Implement multiple authentication flows.
Map each provider's contact fields to your internal model.
Handle provider-specific pagination, rate limits, and errors.
Update each connector when a provider changes its API.

Unified API Approach

With a unified API platform, your application uses one endpoint and one normalized payload:

curl -X POST "https://api.example.com/contacts" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Jane Doe",
    "email": "jane@example.com",
    "company": "Acme Corp"
  }'

The platform maps the request to the connected CRM, manages the provider authentication, and returns a normalized response.

Your implementation should still account for:

Missing fields required by a specific provider
Provider-specific validation failures
Retries for transient failures
Connection expiration and reauthorization
Idempotency when creating or updating records

Popular Unified API Platform Providers

Several platforms operate in the unified API space:

Merge: Focuses on categories such as HRIS, ATS, CRM, and accounting, with data syncing features.
Nango: Supports custom unified APIs with flexible field mapping.
Deck: Connects to traditional APIs and non-API web systems.
CoinStats: A unified API for crypto data, aggregating wallet, portfolio, DeFi, and market data across 120+ blockchains and 200+ exchanges, with an MCP server for AI agents.
Unified.to and Apideck: Provide integration libraries across multiple SaaS categories.

Unified APIs for Crypto and Wallet Data

Unified API patterns also apply to crypto. A portfolio tracker, trading product, or wallet dashboard may need data from many blockchains, exchanges, and wallet types. Each source has its own data format and behavior.

A unified crypto data API provides one consistent interface instead of requiring separate integrations for each chain, exchange, market-data source, and DeFi protocol.

CoinStats API is an example of this approach in the crypto vertical. It provides unified access to on-chain and off-chain data, wallet balances and transactions, portfolio analytics, and market coverage across 120+ blockchains and 200+ exchanges through a consistent interface.

How the Unified Model Applies

Normalized data model: Wallet balances and transactions use the same general structure across Solana, EVM chains, and Bitcoin.
One point of access: One account can reach supported networks and exchanges instead of combining separate market-data, node, and DeFi sources.
Broad coverage through one integration: A single connection covers 120+ blockchains, 200+ exchanges, and 10,000+ DeFi protocols.

Available Data Categories

Wallet data: Balances and transaction history across Solana, EVM chains, and Bitcoin, including HD wallets (xpub, ypub, and zpub).
Portfolio data: Value, holdings, allocation, and profit and loss for a connected portfolio.
DeFi data: Staking, lending, and liquidity positions detected across supported protocols.
Market data: Prices, market caps, volumes, and historical charts for 100,000+ coins.

AI Agent Support

CoinStats also offers an MCP (Model Context Protocol) server. It exposes crypto data as tools for assistants such as Claude, Cursor, and custom agents. This lets an agent access wallet, portfolio, and market data through one connection rather than integrating with each data source independently.

Use Apidog Alongside Unified APIs

A unified API platform handles provider connectivity. An API development platform such as Apidog can help your team design, test, document, and validate the interface your application exposes around that integration layer.

A practical workflow is:

Define your API contract. Model normalized resources such as contacts, companies, connections, and sync jobs.
Document request and response schemas. Specify required fields, validation rules, error formats, and pagination behavior.
Mock provider responses. Simulate successful responses, expired connections, rate limits, and validation errors before connecting to live providers.
Test integration flows. Validate that your backend correctly handles normalized payloads and failure scenarios.
Share interactive documentation. Give frontend teams, partners, or customers a clear contract for using your API.

Apidog can support this workflow through API design and documentation, mocking and testing, and OpenAPI/Swagger import and export.

Evaluation Checklist

Before selecting a unified API platform, answer these questions:

Does it support the integration categories and providers your users require?
Is the normalized model deep enough for your workflows?
Is data fetched in real time, synchronized periodically, or cached?
Can you map custom fields and provider-specific data?
What security and compliance controls are available?
How are errors, retries, monitoring, and provider outages handled?
How are webhooks delivered, verified, retried, and replayed?
Can your team prototype, test, and document the API contract efficiently?

Future Trends

Agent-based integrations: Some platforms use agents to connect with systems that do not expose official APIs.
AI-optimized APIs: Platforms are adding event-driven triggers and action layers for AI agents.
Universal access models: The definition of an API is expanding to include traditional APIs, web portals, and legacy systems.

Conclusion

Unified API platforms reduce the complexity of supporting many third-party integrations. They provide a normalized layer for authentication, data models, provider connectors, and operational concerns so teams can focus on the product experience.

Use a unified API when broad integration coverage and a consistent developer experience matter. Use direct integrations when a single provider requires deep, specialized functionality. In either case, define clear API contracts, test failure paths, and document the integration behavior your users depend on.

Urgent: How to Stop GitHub Copilot from Using Your Code for AI Training (Before April 24)

Preecha — Sat, 11 Jul 2026 13:01:17 +0000

TL;DR

GitHub will start using your Copilot interaction data for AI model training on April 24, 2026. Your code snippets, chat conversations, and acceptance decisions become training data unless you manually opt out. Change your settings at github.com/settings/copilot before the deadline to keep your code private.

Try Apidog today

Introduction

Your Copilot workflow may become training data for future AI models.

On April 24, 2026, GitHub's updated Copilot policy takes effect. Under this change, Microsoft and GitHub can use Copilot interaction data—including code snippets, debugging questions, and refactoring requests—to train future models. This may include proprietary code from private repositories.

If you manage a team or work with sensitive codebases, review your Copilot settings before the deadline and share the opt-out steps with your engineering lead.

What Changed in GitHub's Copilot Policy

GitHub describes the update as a way to “personalize and improve” Copilot experiences. The relevant change is the use of Copilot interaction data for training future AI models.

Policy Timeline

April 24, 2026 is the enforcement date. After that date, GitHub assumes consent unless you manually opt out in your account settings.

GitHub refers to the data as “interaction data.” In practice, this can include the code and context you provide while using Copilot.

What GitHub Collects

Data type	What it includes	Privacy risk
Code snippets	Code you write or modify with Copilot assistance	Proprietary algorithms, business logic, API integrations
Chat conversations	Context from Copilot Chat sessions	Architecture decisions, debugging workflows, system design
Acceptance decisions	Suggestions you accept or reject	Signals about what your team considers “good” code
File context	Surrounding code used to generate suggestions	Database schemas, authentication flows, internal APIs
Correction patterns	How you modify Copilot output	Coding standards and security practices

This data can train GitHub's next-generation models. Once code patterns are incorporated into model weights, they may influence suggestions provided to other users.

Why the Default Matters

GitHub asks users to review the update and manage their preferences. That means privacy protection requires an explicit action from each user.

After April 24, the default is opt-in.

For development teams, this makes Copilot privacy a configuration-management task rather than an individual preference. Treat it like any other security or compliance control: document it, verify it, and enforce it where possible.

Step-by-Step: Opt Out of GitHub Copilot Data Collection

Opting out takes only a few minutes. Complete these steps before April 24.

Method 1: Individual Account Settings

1. Open Copilot settings

Go to github.com.
Click your profile icon in the top-right corner.
Select Settings.
Select Copilot in the left sidebar.

2. Disable AI model training data usage

Scroll to the Privacy section.
Find the option labeled Allow GitHub to use my data for AI model training.
Disable the option.
Confirm that the setting remains disabled.

3. Confirm the change

Allow up to 30 minutes for the preference to take effect.
Restart your code editor if you want the updated setting to apply immediately.

Method 2: Organization-Wide Settings

If you administer a GitHub organization, configure this at the organization level so individual developers do not need to manage it separately.

1. Open organization settings

Go to your organization’s GitHub page.
Click Settings in the organization navigation.
Select Copilot from the left menu.

2. Configure the policy

Find Copilot data usage policies.
Select Disable interaction data collection for all members.
Save the change.

3. Communicate the policy

After applying the setting:

Document the policy in your internal wiki or security handbook.
Notify developers in Slack or email.
Add the setting to onboarding and offboarding checklists.
Record the decision in your compliance or vendor-management documentation.

Verification Checklist

There is no CLI command for verifying this preference. Use the GitHub UI and your internal controls instead:

1. Confirm the training option is unchecked in Copilot settings.
2. Capture a screenshot or configuration record for compliance evidence.
3. Review GitHub data-download options:
   Settings > Privacy > Download your data
4. Recheck organization-level Copilot policies after administrative changes.

Important: Opting out does not delete data already collected. It only prevents future collection from the time you change the setting.

Enterprise and Compliance Considerations

If your team works in a regulated industry or handles sensitive customer data, review this policy change with security, compliance, and legal stakeholders.

Industries That Need Extra Scrutiny

Industry	Regulation	Concern
Healthcare	HIPAA	PHI exposure through code comments or variable names
Finance	SOC 2, GDPR	Customer transaction logic and PII handling patterns
Government	FedRAMP, ITAR	Classified system architecture and security protocols
Enterprise SaaS	Customer contracts	Proprietary algorithms and competitive advantages

Questions for Legal and Compliance Teams

Before April 24, schedule a review and answer these questions:

Does our current MSA with GitHub address AI training data usage?
Do customer contracts prohibit sharing code with third-party AI services?
Could source code, comments, variable names, or API schemas expose regulated data?
What liability exists if proprietary code patterns surface in competitor suggestions?
Do we need an enterprise agreement with explicit data restrictions?

GitHub Enterprise Options

GitHub Enterprise customers may have additional negotiating options. Ask your GitHub account representative about:

Contractual guarantees against training data usage
Private model instances for regulated workloads
Enhanced audit logging for compliance reporting
Custom data-retention policies

Apidog for API Development Privacy

For teams building and testing APIs, privacy extends beyond code completion. Apidog provides a privacy-first alternative to cloud-based API development tools:

Local-first architecture: API specifications stay on your machine.
No training on customer data: Apidog does not use API definitions to train models.
Self-hosted options: Maintain data sovereignty for regulated workloads.
Internal collaboration: Share specifications with your team without third-party exposure.

When evaluating AI-powered development tools, ask:

Where does my data go, and how is it used?

The answer should be documented, clear, and contractually binding.

What Happens If You Do Not Opt Out

If you remain opted in after April 24, your Copilot interaction data can enter GitHub's training pipeline.

Your Code Enters the Training Pipeline

Interaction data is collected in batches.
You may not receive a notification when your data is used.
There may be no mechanism to request deletion after data is incorporated into models.

Potential Exposure Scenarios

A competitor prompts Copilot with similar context.
A model generates suggestions resembling your code or implementation patterns.
There is no audit trail showing which training data influenced a generated output.

Compliance Complications

Customer audits may flag AI training data usage.
Regulatory inquiries may require data mapping that you cannot provide.
Contractual violations may trigger breach-notification requirements.

Can You Opt Out Later?

Yes, but there are limitations:

Data category	Result after opting out
Future data	Collection stops going forward
Historical data	Data may already be incorporated into models; deletion is not guaranteed
Model weights	Even if data is deleted from datasets, models may retain learned patterns

The most direct approach is to opt out before April 24.

Conclusion

GitHub's Copilot policy change takes effect on April 24, 2026. Your interaction data—including code snippets, chat conversations, and acceptance patterns—can become training material for GitHub AI models unless you manually opt out.

Take two minutes to review your Copilot settings, document the decision for your team, and verify organization-level controls where applicable. For API teams that need privacy-focused tooling, explore Apidog: an all-in-one API development platform designed to keep API specifications private by default.

DEV Community: Preecha

Google API Gateway: Complete Guide, Features, & Best Practices

What Is Google API Gateway?

Why Use Google API Gateway?

Core Features

Integrated security

OpenAPI-based configuration

Traffic management

Monitoring and logging

GCP backend integration

Custom domains

Architecture Overview

Set Up Google API Gateway

Step 1: Prepare a backend service

Step 2: Define the OpenAPI specification

Step 3: Create an API config

Step 4: Deploy the gateway

Step 5: Add security requirements

Step 6: Monitor the deployment

Best Practices

Version your API contract

Automate deployments

Require authentication

Set quotas and rate limits

Monitor continuously

Real-World Use Cases

Microservices API aggregation

Mobile application backend

Third-party integrations

IoT device management

Practical Example: Serverless API Deployment

1. Create the function

2. Deploy the function

3. Create openapi.yaml

4. Create the API config and gateway

5. Test the gateway endpoint

Google API Gateway Pricing

Integrating Apidog with Google API Gateway

Design and document APIs

Mock and test endpoints

Collaborate on API contracts

Google API Gateway vs. Other API Management Solutions

Frequently Asked Questions

Is Google API Gateway only for REST APIs?

Can I use custom domains with Google API Gateway?

How do I secure APIs with Google API Gateway?

Can I monitor API usage in real time?

Next Steps

How to Manage Internal vs External API: Complete Guide

What Does Managing Internal vs External APIs Mean?

Internal vs External API Management

Internal APIs: Private and Fast-Moving

External APIs: Public or Partner-Facing

How to Manage Internal vs External APIs

1. Define API Ownership and Governance

2. Apply Different Access Controls

3. Treat Documentation as Part of the API Contract

4. Secure Both API Types

5. Monitor the Metrics That Matter

6. Use Versioning and Lifecycle Policies

7. Test With Mocks and Sandboxes

How Apidog Helps Manage Internal and External APIs

Practical Examples

Example 1: Internal API for an HR Dashboard

Example 2: External API for Order Processing

Example 3: Hybrid API Strategy for a SaaS Platform

Conclusion

How to Use Hootsuite API ?

TL;DR

Introduction

Hootsuite API Status and Alternatives

Current API Situation

Recommended Approach: Native Platform APIs

Getting Started: Multi-Platform Authentication

Step 1: Register Developer Apps

Step 2: Generate OAuth 2.0 Authorization URLs

Step 3: Exchange the Authorization Code for Tokens

Step 4: Store Tokens Securely

Post Scheduling and Publishing

Define a Shared Post Payload

3. Create `openapi.yaml`