.png)
Azure API Management Integration Guide
Connect Martini workflows and APIs with REST, GraphQL, and SOAP services published, secured, and governed through Azure API Management.
Azure API Management integration options at a glance
Azure API Management primarily exposes and governs REST APIs, with support for GraphQL publishing and SOAP pass-through or SOAP-to-REST scenarios. It applies subscription keys, OAuth 2.0 and JWT validation, certificates, managed identities, network controls, throttling, transformation, routing, and telemetry at the gateway. Martini can consume APIs published through the gateway, call Azure management interfaces where authorized, or expose Martini REST APIs behind Azure API Management. Incoming HTTP webhook-style requests can be received by published APIs, but Azure API Management is not a general-purpose outbound event platform. Martini provides orchestration, mapping, synchronization, retries, and business rules.
| Integration point | Supported by Azure API Management? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | REST and HTTP APIs are Azure API Management's primary use case, including API import, publication, routing, policy enforcement, transformation, throttling, and backend protection. | Martini can consume REST APIs published through the gateway or expose a REST API for Azure API Management to publish. Workflows handle mapping, orchestration, and errors. |
| GraphQL APIs | Yes | Azure API Management can publish and manage GraphQL APIs, although available policies and behavior may differ from REST APIs. | Martini can consume GraphQL APIs through its GraphQL API capabilities and transform responses into downstream models or workflows. |
| SOAP APIs | Limited | SOAP APIs can be imported and exposed through pass-through or SOAP-to-REST scenarios, with REST remaining the dominant model. | Martini can consume SOAP services or a SOAP-derived REST façade and handle XML mapping, authentication, and error processing. |
| Webhooks / inbound HTTP callbacks | Limited | Azure API Management can publish an HTTP endpoint that receives webhook-style requests from an external producer, then validate, transform, throttle, and route them. | Martini can expose a REST API or receive webhook requests through a workflow, but the external application or Azure service must produce the event. |
| Authentication | Yes | Gateway and backend security can use subscription keys, OAuth 2.0, JWT validation, client certificates, managed identities, Basic Authentication, IP restrictions, and network controls. | Martini can store credentials in protected configuration and call gateway APIs with the required headers, tokens, certificates, or authentication configuration. |
| XML and JSON transformation | Yes | Azure API Management policies can transform XML and JSON requests and responses, rewrite headers and URLs, and apply validation at gateway stages. | Martini can perform more complex mapping, transformation, validation, enrichment, and multi-system orchestration in workflows. |
| Azure management APIs and SDKs | Yes | Azure Resource Manager APIs and Azure SDKs support provisioning and management of API Management resources, subject to Microsoft Entra ID and Azure RBAC. | Martini can call authorized management endpoints through API workflows when resource administration is part of the integration scope. |
| Monitoring and diagnostics | Yes | Azure Monitor, diagnostic settings, and Application Insights provide gateway telemetry, metrics, logs, diagnostics, and backend performance information. | Martini can consume configured monitoring endpoints or exported telemetry where permissions and endpoints are available, and can correlate workflow logs with gateway request identifiers. |
How Azure API Management exposes data and business events
Azure API Management REST APIs
REST and HTTP APIs are Azure API Management's primary integration mechanism. The gateway can import and publish APIs, route requests, enforce authentication and subscriptions, transform payloads, throttle consumers, and protect backend services.
Martini implementation pattern
Martini implementation pattern: configure a Martini workflow to call the API Management gateway URL, provide the required subscription key or OAuth token, validate the response, and map the result into a canonical or downstream model. Martini can also expose a REST API that Azure API Management publishes and secures.
Implementation sequence
Azure API Management GraphQL APIs
Azure API Management supports publishing and managing GraphQL APIs. GraphQL policy coverage and request behavior can differ from REST, so the published schema and gateway configuration should be treated as the contract.
Martini implementation pattern
Martini implementation pattern: configure GraphQL consumption with the gateway endpoint and required authentication, submit the required query and variables, then normalize the selected response fields for downstream processing. Martini can orchestrate additional API calls when a single GraphQL response is not sufficient.
Implementation sequence
Azure API Management SOAP APIs
Azure API Management can import and expose SOAP APIs through pass-through or SOAP-to-REST scenarios. The backend contract, WSDL, XML namespaces, and gateway transformation behavior determine the supported interaction.
Martini implementation pattern
Martini implementation pattern: consume the SOAP endpoint or REST façade with the corresponding Martini SOAP or REST configuration, preserve required XML envelopes and namespaces, and transform the result for modern downstream systems. Complex multi-system orchestration remains in Martini workflows rather than gateway policies.
Implementation sequence
Common Azure API Management integration patterns
Pattern 1: Publish Martini APIs through Azure API Management
When to use this pattern
Use this pattern when Martini owns business orchestration but Azure API Management should provide the public gateway, subscription controls, OAuth or JWT validation, rate limits, routing, and common request policies.
Integration direction
Example Mapping
| Azure API Management Field | Canonical Field | Target Field |
|---|---|---|
| request.customerId | customerIdentifier | Martini API customerId |
| request.operation | businessOperation | Martini workflow operation |
| response.status | processingStatus | client response status |
Martini implementation pattern
Expose a Martini REST API backed by a workflow that validates the request, calls required systems, applies business rules, and returns a controlled response. Azure API Management publishes the endpoint and enforces gateway concerns; Martini handles application errors and downstream retries.
Martini capabilities used
- API exposure
- workflows
- data mapping
- business rules
- error handling
Pattern 2: Consume gateway APIs for scheduled synchronization
When to use this pattern
Use this pattern when Martini must periodically retrieve data from an API published through Azure API Management and synchronize it with another application or data store.
Integration direction
Example Mapping
| Azure API Management Field | Canonical Field | Target Field |
|---|---|---|
| source.id | externalIdentifier | external_id |
| source.updatedAt | lastModifiedAt | modified_at |
| source.status | lifecycleStatus | status |
Martini implementation pattern
A scheduler-triggered Martini workflow calls the gateway API, follows the API's pagination or continuation model, filters by a modification checkpoint where supported, maps each payload, and performs idempotent writes. It records checkpoints only after successful processing and applies bounded backoff to 429 and transient 5xx responses.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- checkpointing
- retry handling
Pattern 3: Modernize SOAP services with an API façade
When to use this pattern
Use this pattern when Azure API Management exposes an imported SOAP service through pass-through or a SOAP-to-REST façade and Martini must normalize the service for other applications.
Integration direction
Example Mapping
| Azure API Management Field | Canonical Field | Target Field |
|---|---|---|
| customerNumber | customerIdentifier | CustomerNumber |
| order.total | orderAmount | OrderTotal |
| response.resultCode | processingStatus | ResultCode |
Martini implementation pattern
Martini consumes the gateway's SOAP or REST-compatible contract, transforms XML and namespaces into a canonical model, enriches or routes the request, and invokes additional systems when required. SOAP faults, gateway errors, and backend failures are classified separately for retry and reconciliation.
Martini capabilities used
- SOAP API consumption
- XML transformation
- workflows
- routing
- error handling
Pattern 4: Route inbound HTTP notifications to business workflows
When to use this pattern
Use this pattern when an external application or Azure service sends webhook-style HTTP requests to an endpoint published through Azure API Management. The event producer remains responsible for generating the notification.
Integration direction
Example Mapping
| Azure API Management Field | Canonical Field | Target Field |
|---|---|---|
| event.id | eventIdentifier | correlation_id |
| event.type | eventType | workflow_event_type |
| event.data | businessPayload | target request body |
Martini implementation pattern
Azure API Management validates, throttles, transforms, and routes the incoming request to a Martini API. Martini verifies required fields, applies duplicate-safe processing using the event identifier, executes the business workflow, and returns an appropriate response while recording failures for replay or reconciliation.
Martini capabilities used
- API exposure
- webhook consumption
- validation
- business rules
- idempotency
- error handling
Applications commonly integrated with Azure API Management
Azure API Management commonly sits between enterprise consumers, application services, and backend APIs. The following products represent practical integration targets or backends; Azure API Management does not provide dedicated application connectors for them, so Martini or the backend uses each product's supported API and authentication model.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Azure Functions | Publish serverless business logic through a governed API façade with centralized authentication, quotas, transformation, and monitoring. | Azure Functions → Azure API Management → Martini | Martini consumes the published gateway API, supplies the required subscription key or bearer token, maps the response, and routes errors or retries according to the operation contract. |
| Azure App Service | Expose REST services hosted on App Service through a controlled gateway and provide a consistent interface for downstream consumers. | Azure App Service → Azure API Management → Martini | A Martini workflow calls the API Management URL, transforms JSON or XML payloads, applies business rules, and writes the result to downstream systems. |
| Azure Logic Apps | Secure and govern workflow endpoints while allowing API consumers and integration processes to exchange business data through managed interfaces. | Azure Logic Apps → Azure API Management → Martini | Martini invokes a published Logic Apps endpoint or exposes a Martini API that Logic Apps calls, with gateway authentication handled separately from workflow orchestration. |
| Azure Service Bus | Place an API façade in front of services that publish messages to queues or topics, while keeping messaging operations in the backend implementation. | Martini → Azure API Management → Azure Service Bus | Martini calls the gateway API, maps the request into the backend contract, and relies on the backend service to publish to Service Bus; response and failure handling remain in the Martini workflow. |
| Microsoft Dynamics 365 | Provide governed access to Dynamics 365 APIs, normalize payloads, and protect downstream business services with gateway policies. | Martini → Azure API Management → Microsoft Dynamics 365 | A Martini workflow consumes the relevant Dynamics API through the gateway, stores credentials securely, maps business objects, and handles pagination, throttling, and duplicate-safe writes. |
| Salesforce | Centralize access to Salesforce APIs and provide a controlled façade for internal consumers or Martini-led data synchronization. | Martini → Azure API Management → Salesforce | Martini calls the API Management endpoint, transforms Salesforce responses into a canonical model, and applies bounded retries for throttling or transient backend failures. |
| SAP S/4HANA | Publish or protect SAP REST, OData, or SOAP services behind a managed API boundary for enterprise applications. | Martini → Azure API Management → SAP S/4HANA | Martini consumes the exposed SAP service, handles XML or JSON transformation, applies validation and routing rules, and preserves correlation identifiers across the gateway and backend. |
| ServiceNow | Provide controlled access to ServiceNow APIs or expose Martini workflows for incidents, requests, and configuration-related processes. | ServiceNow → Azure API Management → Martini | Martini consumes or exposes REST APIs through the gateway, maps ServiceNow payloads, applies workflow rules, and records request identifiers for reconciliation. |
How to build a Azure API Management integration in Martini
Objective
Establish network reachability to the Azure API Management gateway or management endpoint and identify the authentication model required by the selected API.
Instructions in Martini
- Confirm whether the gateway is public, private, or network restricted
- Choose the required subscription key, OAuth 2.0 token, certificate, managed identity, or other confirmed credential
- Store keys, tokens, certificates, and endpoints in protected Martini configuration
- Separate gateway consumer authentication from Azure management-plane Entra ID and RBAC requirements
Objective
Select an event-driven API request, inbound webhook-style request, scheduled workflow, or API-led invocation based on the backend contract and synchronization objective.
Instructions in Martini
- Use a REST, GraphQL, or SOAP API trigger when a consumer invokes Martini
- Use a webhook-style endpoint only when an external producer sends the request
- Use a scheduler for polling and incremental synchronization
- Define correlation identifiers and expected retry behavior before implementation
Objective
Call the published gateway operation or receive the request while preserving the API contract, status codes, headers, and correlation information needed for processing.
Instructions in Martini
- Invoke the Azure API Management URL with the configured authentication
- Handle pagination, continuation tokens, next links, or modification filters defined by the backend API
- Capture request identifiers and relevant rate-limit or retry headers
- Distinguish gateway responses from backend responses
Objective
Use a Martini workflow to coordinate validation, enrichment, multiple API calls, routing, and downstream writes while keeping gateway policy concerns separate from business logic.
Instructions in Martini
- Validate required request and response fields
- Call dependent systems in the required order
- Apply conditional routing and business rules in the workflow
- Keep complex orchestration out of Azure API Management policies
Objective
Convert JSON, XML, GraphQL, or SOAP payloads into canonical and target-specific models without relying on undocumented gateway-generated fields.
Instructions in Martini
- Map vendor and backend fields to stable internal names
- Transform XML namespaces, SOAP envelopes, content types, or JSON structures as required
- Normalize dates, identifiers, statuses, and numeric values
- Validate the transformed model before writing it to a target
Objective
Persist or deliver the processed result to the target system with duplicate-safe behavior and a clear record of the source and target identifiers.
Instructions in Martini
- Use an idempotency key or business correlation identifier where supported
- Write only after validation and required enrichment succeed
- Persist checkpoints after successful synchronization units
- Return a response that reflects accepted, completed, or failed processing
Common Azure API Management data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| APIs | Logical API definitions published through the gateway, including operations, policies, schemas, revisions, and versions. | Martini APIs, Azure Functions, Azure App Service, SAP S/4HANA, Salesforce, ServiceNow | Martini consumes the API contract through REST, GraphQL, or SOAP configuration, maps payloads, and can expose a separate API for Azure API Management to publish. |
| Operations | Individual HTTP operations such as customer retrieval, order submission, or status updates. | Martini workflows, backend application services, databases, SaaS APIs | Martini workflows invoke operations, validate inputs, apply operation-specific business rules, and handle status codes and response mappings. |
| Products | Collections of APIs published to selected developer groups and protected through subscriptions. | API consumers, Martini runtimes, internal application teams | Martini supplies the subscription credentials required by the published API and treats product-level quotas as part of retry and throughput design. |
| Subscriptions | Credentials and access relationships used by consumers to call products or APIs. | Martini environment configuration, API consumers, Azure API Management gateway | Martini stores subscription keys as protected environment values and sends them in the configured header or query parameter without embedding secrets in workflow logic. |
| Policies | XML-based inbound, backend, outbound, and error-stage rules for authentication, authorization, throttling, caching, routing, validation, and transformation. | Azure API Management gateway, backend APIs, Martini APIs | Martini relies on gateway policies for common edge concerns and keeps complex orchestration, mapping, and business rules in workflows. |
| Backends | Named targets representing Azure Functions, App Service applications, HTTP services, or other API endpoints. | Azure services, on-premises APIs, external applications, Martini APIs | Martini calls the gateway endpoint while Azure API Management routes to the configured backend; correlation and backend error details are preserved for troubleshooting. |
Authentication and security considerations
Separate gateway and management-plane security
Gateway consumers may authenticate with subscription keys, OAuth 2.0 and JWT validation, client certificates, Basic Authentication, or network controls. Azure management operations generally use Microsoft Entra ID and Azure RBAC rather than API consumer subscription keys.
Protect credentials and tokens
- Store subscription keys, client secrets, certificates, and tokens in protected Martini configuration.
- Validate issuer, audience, scopes, claims, and expiration when bearer tokens are required.
- Use TLS, private networking, IP restrictions, and certificate validation according to the deployment model.
- Do not expose gateway credentials, internal backend URLs, or sensitive policy details in error responses.
Operational considerations for Azure API Management integrations
Quotas, pagination, and retries
Azure API Management can enforce product, subscription, API, and backend limits, while the backend may impose additional constraints. Handle 429 responses with bounded backoff, follow the published pagination model, and avoid retrying non-idempotent operations without an idempotency strategy.
Contracts and observability
- Capture gateway and backend status codes, request identifiers, trace identifiers, latency, and policy failures.
- Treat OpenAPI, WSDL, and GraphQL schema changes as contract changes and test mappings against revisions or versions.
- Distinguish gateway failures from backend failures during retry and reconciliation.
- Confirm DNS, firewall, private endpoint, TLS, and outbound routing requirements before production deployment.
Why use Martini instead of scripts or point-to-point integrations?
Keep gateway concerns separate from business orchestration
Azure API Management is well suited to publishing APIs and enforcing authentication, subscriptions, throttling, routing, lightweight transformation, and telemetry. Martini provides the workflow layer for multi-system orchestration, complex mapping, validation, enrichment, business rules, checkpointing, and duplicate-safe processing.
Build maintainable integration assets
- Use reusable workflows and exposed APIs instead of scattered scripts.
- Centralize credentials and environment-specific configuration.
- Handle retries, errors, pagination, and reconciliation consistently.
- Keep API gateway policy changes and application integration logic independently maintainable.
Frequently asked questions
Azure API Management integrates by publishing and governing REST APIs, GraphQL APIs, and supported SOAP services. It can secure, route, transform, throttle, validate, and monitor API traffic between consumers and Azure, external, or on-premises backends. Martini can consume these gateway APIs, expose APIs behind the gateway, and orchestrate synchronization or business processes around them.
Yes. Martini can consume REST, GraphQL, and SOAP APIs exposed through Azure API Management, using the gateway's configured subscription keys, OAuth 2.0 tokens, certificates, or other supported authentication methods. Martini can also expose a REST API that Azure API Management publishes and protects.
No. A dedicated Azure API Management connector is not required. Martini can use the vendor's native REST, GraphQL, and SOAP endpoints, receive HTTP requests through an API published by the gateway, and use the configured authentication mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Azure API Management. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Microsoft Azure, Azure API Management, network infrastructure, or other third-party services based on subscription, usage, and deployment model.
REST is the primary method for new integrations. GraphQL is available when the published schema and policy requirements fit the use case, while SOAP is appropriate for supported pass-through or SOAP-to-REST modernization scenarios. Martini can consume each protocol and keep complex transformation and orchestration in workflows.
Azure API Management can expose an HTTP endpoint that receives webhook-style requests from an external producer, but it is not a general-purpose outbound event producer. Outbound event delivery normally requires an external application, Azure Function, Logic App, eventing service, or other backend that invokes the target endpoint.
Synchronization depends on the API published behind the gateway. Martini can run scheduled workflows, call paginated or incremental API operations, persist checkpoints, transform payloads, and perform idempotent writes. Gateway quotas and backend limits should be incorporated into throughput, retry, and reconciliation design.
Yes. Martini can expose a REST API backed by workflows, and Azure API Management can publish that endpoint as a managed gateway API. Azure API Management can enforce subscriptions, JWT validation, quotas, rate limits, routing, and common transformations while Martini performs business orchestration, mapping, and backend calls.
Related Martini documentation
API Consumption
Workflows
Connect Azure API Management with Martini
Use Martini to consume APIs published through Azure API Management or expose Martini workflows behind its gateway, with secure configuration, transformation, orchestration, and operational controls.