Skip to content
  • Machine-to-Machine (M2M)
  • Overview

Top questions about M2M applications

Here are short answers to the most common M2M questions. Click any question to expand the answer.

Core concepts and setup

Link to this section
What is the difference between machine-to-machine and user authentication in Kinde?

M2M authentication is for servers, APIs, and automated systems that communicate without user interaction. Unlike user authentication (password, social sign-in, or SSO), M2M uses the OAuth 2.0 client credentials flow: the application authenticates with a client ID and secret to obtain an access token. This pattern is commonly used for microservices, background jobs, and system integrations.

About machine-to-machine applications

How do I create and configure a machine-to-machine application in Kinde?

Create a new application in the Kinde dashboard and select “Machine to machine” as the app type. Kinde issues a client ID and client secret. M2M applications do not require callback URLs because there is no user redirect flow. Assign API access and scopes based on least privilege, then expand only when required.

Create machine-to-machine application

What are the security best practices for storing Kinde M2M credentials?

Do not store M2M credentials in source code or version control. Use environment variables and a secrets manager (for example AWS Secrets Manager, Azure Key Vault, or Google Secret Manager), or your platform secure configuration system. Rotate client secrets regularly, especially after potential exposure. Use separate M2M applications per environment (development, staging, production) to reduce blast radius.

Machine-to-machine token structure

When should I use multiple M2M applications versus one application with broad permissions?

Apply least privilege by creating separate M2M applications for distinct services or workflows. This limits impact if one credential is compromised and improves auditability because API calls map to a specific integration.

Create machine-to-machine application

How do I handle Kinde M2M token expiration in production systems?

M2M access tokens expire (usually after an hour), so your application needs to handle token refresh gracefully. Most Kinde SDKs handle this automatically, but if you’re doing it manually, implement retry logic that gets a fresh token when you receive 401 responses. Cache tokens in memory and refresh proactively before expiry. For high-traffic systems, use a short-lived, in-memory cache per host/process to reduce token requests. Do not share tokens across services or persist them.

About machine-to-machine applications

Does M2M use refresh tokens or only client credentials?

M2M uses the client credentials flow only; there are no refresh tokens. You obtain access tokens by authenticating with your client ID and client secret. When an access token expires, request a new one using the same client credentials. Do not use or expect a refresh token.

About machine-to-machine applications | Authenticate with M2M

API access and scopes

Link to this section
What Kinde API scopes do I need for different M2M use cases?

Scope requirements depend on operations. For user management, common scopes include read:users and write:users; for organization workflows, include read:organizations and write:organizations; billing integrations require billing-related scopes. Start with minimal scopes and expand as needed based on endpoint requirements.

Add APIs to machine-to-machine applications

How do I call Kinde APIs from my M2M application without getting rate limited?

Respect rate limits and implement exponential backoff on throttled responses. Batch operations where possible, use bulk endpoints for high-volume workflows, and cache low-change data to reduce repeated calls. If limits are still reached after optimization, contact Kinde support with traffic details.

Authenticate with M2M

How should I handle Kinde Management API responses in M2M applications?

Always check HTTP status codes before processing response bodies. Parse JSON defensively, including missing or optional fields. Implement pagination for list endpoints. Log response metadata for debugging, but never log credentials or access tokens. Use idempotent writes where possible so retries do not create duplicate side effects. Troubleshoot M2M token errors

How do I test Kinde M2M integrations safely without affecting production data?

Use separate M2M applications per environment to isolate test and production data. Create dedicated test organizations and users. Configure CI/CD to use non-production credentials. Mock API responses in unit tests, and validate failure handling for timeouts, errors, and malformed responses.

Create machine-to-machine application

Integration patterns

Link to this section
How should I structure Kinde M2M calls for microservices architecture?

Each microservice should have its own M2M application with only the permissions it needs - this follows the principle of least privilege and makes security auditing much easier. Consider creating a shared authentication service that handles token management for all your microservices, or use a service mesh that can inject tokens automatically. Don’t pass M2M tokens between services - each service should authenticate directly with Kinde. This prevents token leakage and makes it easier to track which service is making which API calls.

About machine-to-machine applications

How should I sync user data between Kinde and my application using M2M?

Use webhooks for near-real-time change notifications, then call M2M APIs to fetch updated records as needed. Avoid maintaining a full mirror unless required; instead, cache frequently accessed fields and refresh authoritative data for critical operations. Use retry logic and eventual-consistency patterns where acceptable.

Sync data in Kinde

How do I handle Kinde organization management through M2M applications for multi-tenant SaaS?

M2M is well suited to automated organization provisioning. You can create organizations, assign initial users and permissions, and apply billing configuration through the Management API. Use stable naming conventions and store Kinde organization IDs in your internal records for reliable mapping.

M2M apps for organizations

How can I use Kinde M2M applications to automate user provisioning workflows?

Set up M2M workflows for user creation, organization assignment, and initial permission setup based on business rules. Trigger these from webhooks, scheduled jobs, or upstream system events. Include handling for duplicates, quota constraints, and reconciliation.

Machine-to-machine auth flow

Troubleshooting and monitoring

Link to this section
Why is my Kinde M2M application getting authentication errors in production?

Start with credential validation for the target environment. M2M credentials are environment-specific, so development credentials do not work in production. Use error codes to isolate root causes: invalid_client typically indicates credential issues, while insufficient_scope indicates missing permissions. If failures begin after a period of success, verify credential rotation and scope changes.

M2M API scopes

How do I monitor and debug Kinde M2M API performance issues?

Implement logging for request latency, error rates, and token refresh behavior. Use correlation IDs to trace cross-service calls. Configure alerts for authentication failures and abnormal traffic patterns. Kinde dashboard metrics are helpful, but production systems should also use dedicated application monitoring.

Test API with M2M tokens

What should I do when my Kinde M2M application needs higher rate limits?

First, optimize request patterns by removing unnecessary calls, batching workloads, and caching low-change data. Ensure pagination is implemented for large datasets. If higher limits are still required, contact Kinde support with your use case, expected traffic, and optimization steps already taken.

API rate limits

How do I handle intermittent failures when calling Kinde APIs from M2M applications?

Design resilience for intermittent network and service failures. Use exponential backoff with jitter, reasonable timeouts, and circuit breakers for critical paths. Log enough context for diagnosis without excessive retry noise. For non-critical tasks, use queues so retries do not block primary workflows.

Troubleshoot M2M

Advanced use cases

Link to this section
How can I use Kinde M2M applications for automated user lifecycle management?

Use M2M automation for lifecycle tasks such as account provisioning, deactivation, and permission updates. Trigger workflows via webhooks, then apply changes through M2M API calls. For enterprise onboarding, you can automate organization setup and authentication configuration. Maintain audit logs for compliance and traceability.

Management API integration

How should I use Kinde M2M in serverless functions and background jobs?

Serverless functions are a good fit for M2M because they can request short-lived tokens per execution without long-term token storage. For background jobs, use token caching with explicit expiration handling. Account for cold-start latency where authentication response time is critical.

Example of using M2M for AI

How do I implement Kinde M2M for data synchronization between multiple systems?

Design synchronization jobs to be idempotent so repeated execution does not create duplicates. Query incremental changes through the Management API, then apply updates downstream. Implement retry logic and failure handling. For near-real-time requirements, use queues or event streams. Validate sync behavior with high-volume test data before production rollout.

Data sync in Kinde

How can I leverage Kinde M2M applications for compliance and audit requirements?

M2M applications support automated compliance workflows, including access reporting, permission-audit checks, and automated revocation for inactive users. Use the Management API to query relevant activity and organization changes, then format outputs for compliance processes. Schedule policy checks and maintain a complete operation audit trail.

Management API overview