This chapter covers Azure Logic Apps connectors and custom connectors, a key topic in the AZ-204 exam domain 'Integrate' (Objective 5.1). You will learn how to use built-in connectors to integrate with SaaS services, how to create custom connectors to extend integrations to custom APIs, and how to handle authentication, policies, and troubleshooting. Approximately 10-15% of the exam questions relate to this area. Mastery of connectors is critical because Logic Apps are a primary tool for building enterprise integration solutions on Azure.
Jump to a section
Imagine a factory that assembles custom products. The factory has a main conveyor belt (the Logic App workflow) that moves items through various stations (connectors). Each station is a specialized machine that can perform a specific task: one station reads barcodes from a database (SQL connector), another sends email notifications (Office 365 Outlook connector), and another communicates with external suppliers via a custom protocol (custom connector). The factory manager designs the workflow by dragging and dropping these stations onto the belt and configuring each with the correct parameters (connection strings, API keys). When a new order arrives (HTTP trigger), it starts the belt. The item moves from station to station; if a station fails, the belt can retry or divert to a repair station (error handling). Crucially, each station has a specific interface: some accept only certain box sizes (REST API with JSON), some require a special key to operate (authentication). If the factory needs to talk to a new supplier that uses a unique shipping system, they build a custom station (custom connector) that translates the factory's standard box format into the supplier's format. The factory's overall efficiency depends on how well these stations are configured and how they handle rate limits (throttling) and timeouts. The factory is managed through a central control room (Azure portal) where the manager can monitor each station's performance and view logs.
What Are Logic Apps Connectors?
Connectors are the building blocks of Azure Logic Apps. They are pre-built or custom wrappers around APIs that allow your logic app to interact with various services, databases, and systems. Each connector provides a set of operations (triggers and actions) that you can use in your workflow. For example, the Office 365 Outlook connector provides triggers like 'When a new email arrives' and actions like 'Send an email'. Connectors handle the underlying protocol details (HTTP, authentication, retry policies) so you can focus on business logic.
How Connectors Work Internally
When you add a connector action to a logic app, the Logic Apps runtime makes an HTTP request to the connector's API endpoint. The connector translates the request into the specific API call required by the target service. For example, if you use the 'Send an email' action of the Office 365 Outlook connector, the connector constructs a REST API call to Microsoft Graph API with the appropriate OAuth 2.0 token. The response is then parsed and made available to subsequent actions.
Types of Connectors
Built-in connectors: These are managed by Microsoft and run natively within the Logic Apps runtime. They include connectors for Azure services (Blob Storage, Service Bus, SQL Server), Office 365, Dynamics 365, and more. They do not require an API connection resource and are generally faster.
Managed connectors: These are hosted by Microsoft and are invoked via the connector infrastructure. They include connectors for third-party services like Salesforce, Twitter, Dropbox, etc. They require an API connection resource that stores connection parameters and authentication.
Custom connectors: These are wrappers around your own APIs. You create a custom connector by providing an OpenAPI definition (Swagger) or a Postman collection. Custom connectors can be used within your organization or shared with others via the Azure Marketplace.
Creating a Custom Connector
To create a custom connector, you need: 1. An API that is accessible over HTTP and returns responses in JSON or XML. 2. An OpenAPI definition (Swagger 2.0) that describes the API's endpoints, parameters, and authentication requirements. 3. Optionally, a Postman collection that includes example requests and responses.
Steps:
In the Azure portal, navigate to Logic Apps Custom Connector.
Click 'Create custom connector'.
Provide a name, upload the OpenAPI definition, and configure security (authentication type: OAuth 2.0, API Key, Basic Auth, or No Auth).
Define the connector's actions and triggers based on the API definition.
Test the connector using the portal's test functionality.
Once created, you can use the custom connector in any logic app within the same region.
Authentication Mechanisms
Custom connectors support several authentication types: - API Key: The connector sends a key in the header or query parameter. You must specify the key parameter name and location. - Basic Auth: Username and password are sent in the Authorization header. - OAuth 2.0: The connector uses an OAuth 2.0 flow (authorization code, client credentials, etc.). You must configure the authorization endpoint, token endpoint, client ID, client secret, scopes, and redirect URL. - No Authentication: For public APIs.
Policies and Transformation
You can apply policies to custom connectors to modify request/response behavior. For example: - Set HTTP header: Add or override headers. - Set query parameter: Add or override query parameters. - Replace string: Replace a string in the request or response body. - Validate JWT: Check the validity of a JSON Web Token in the request.
Policies are defined in XML and are applied at the connector level. They allow you to enforce security or transform data without modifying the underlying API.
Error Handling and Retries
By default, Logic Apps retries failed actions up to 4 times with exponential backoff (interval: 10 seconds, 20 seconds, 40 seconds, and 80 seconds). You can configure custom retry policies in the action settings. For custom connectors, you can also define policies to handle specific HTTP status codes (e.g., 429 Too Many Requests) by implementing a retry-after policy.
Integration with API Management
Custom connectors can be used in conjunction with Azure API Management (APIM). You can expose your API through APIM and then create a custom connector that points to the APIM endpoint. This adds benefits like caching, rate limiting, and analytics. However, for the AZ-204 exam, focus on the custom connector creation process and authentication.
Performance Considerations
Throttling: Logic Apps has limits on the number of actions per 5-minute rolling window (default: 100,000 actions). Connectors also have their own throttling limits (e.g., Office 365 Outlook: 30 requests per minute per user). Custom connectors inherit the limits of the underlying API.
Timeouts: HTTP actions have a default timeout of 120 seconds for synchronous calls and 5 minutes for asynchronous calls. Custom connectors can have longer timeouts if the API supports it.
Large messages: Logic Apps have a maximum message size of 100 MB (including base64 encoding). For larger payloads, use chunked transfer or store data in Azure Blob Storage and pass a reference.
Monitoring and Troubleshooting
Use the Logic Apps Designer's run history to view each action's inputs, outputs, and status. For custom connectors, enable logging in Application Insights to capture detailed telemetry. Common issues include:
Authentication failures: Check that the API key or OAuth tokens are correctly configured.
Invalid Swagger: Ensure the OpenAPI definition is valid and matches the actual API behavior.
Network restrictions: If the API is behind a firewall, ensure the Logic Apps service IP addresses are whitelisted (see Azure documentation for the list).
Exam-Relevant Details
The AZ-204 exam expects you to know when to use a custom connector vs. a built-in HTTP action. Use a custom connector when you need to reuse the API integration across multiple logic apps, or when you want to provide a rich experience with Swagger-defined operations.
You must understand the authentication options: API Key, Basic Auth, OAuth 2.0. OAuth 2.0 is the most common for production scenarios.
Be aware that custom connectors are regional resources. They are not available across regions unless you recreate them.
The exam may ask about policies: you can add policies to modify requests/responses, but you cannot change the underlying API code.
Know the difference between built-in and managed connectors: built-in connectors are faster and don't require an API connection resource.
Summary of Key Values
Default retry count: 4
Default retry interval: exponential backoff starting at 10 seconds
HTTP action timeout: 120 seconds (sync), 300 seconds (async)
Maximum message size: 100 MB
Action limit per 5 minutes: 100,000
Custom connector Swagger version: 2.0
Example: Creating a Custom Connector for a Weather API
Suppose you have a weather API that requires an API key and returns JSON. You create a custom connector:
1. Upload the OpenAPI definition with the endpoint https://api.weather.com/v1/current and parameter apiKey.
2. Set authentication to API Key, specify the key name apiKey and location query.
3. Define an action 'GetCurrentWeather' with required parameters (city).
4. Test the connector by entering a city name; the connector should return the weather data.
5. Use the connector in a logic app: trigger on a schedule, call 'GetCurrentWeather', and send an email with the results.
This example illustrates the core workflow: define the API, configure auth, test, and use.
Advanced: Custom Connector with OAuth 2.0
For APIs that use OAuth 2.0, you need to register your custom connector as an application in the identity provider (e.g., Azure AD). The custom connector will use the authorization code flow: the user signs in, grants consent, and the connector receives an access token. The connector stores the token and refreshes it automatically. The redirect URL for the connector is https://logic-apis-westus.consent.azure-apim.net/redirect (region-specific). You must configure this redirect URL in your app registration.
Common Pitfalls
Mismatched Swagger: The OpenAPI definition must exactly match the API's actual endpoints and parameters. A mismatch causes runtime errors.
Incorrect redirect URL: For OAuth, if the redirect URL is not configured correctly, the authorization flow fails.
API key exposure: Avoid hardcoding API keys in the connector definition; use connection parameters that are set at runtime.
Region limitation: Custom connectors are tied to the region where they are created. If you need them in multiple regions, you must create copies.
Conclusion
Connectors are essential for integrating Logic Apps with external services. Custom connectors extend this capability to your own APIs. Understanding how to create, authenticate, and troubleshoot connectors is crucial for the AZ-204 exam and real-world integration solutions.
Identify the API to integrate
Determine the external service or custom API you want to connect to. Ensure it has a RESTful interface that returns JSON or XML. Note the authentication method required (API key, OAuth 2.0, etc.) and gather necessary credentials. For custom APIs, you may need to document the endpoints, request/response formats, and error codes.
Create an OpenAPI definition
Write a Swagger 2.0 specification that describes the API's operations. Include paths, parameters, request bodies, responses, and security definitions. Use tools like Swagger Editor or Postman to generate the definition. Ensure the definition is valid and includes all actions you intend to expose as triggers or actions. For triggers, the definition must include a webhook or polling mechanism.
Create the custom connector in Azure
In the Azure portal, navigate to Logic Apps Custom Connector and click 'Create'. Provide a name, upload the OpenAPI definition, and configure security. Choose authentication type (API Key, Basic, OAuth 2.0, or None). For OAuth 2.0, provide authorization URL, token URL, client ID, client secret, scopes, and redirect URL. Click 'Create' to deploy the connector.
Test the custom connector
After creation, use the 'Test' tab in the custom connector blade. Select an action or trigger, provide required parameters, and run the test. The portal will make a real HTTP request to the API and display the response. Verify that the connector handles authentication correctly and returns expected data. Fix any issues by updating the OpenAPI definition or security settings.
Use the connector in a Logic App
Create or open a Logic App in the same region as the custom connector. In the designer, under 'Custom', you will see your connector. Add a trigger or action from the connector. Configure the connection by providing the necessary parameters (e.g., API key). Save the logic app and run it. Monitor the run history to ensure the connector executes successfully.
Enterprise Scenario 1: Integrating a Legacy CRM with Office 365
A company uses a legacy on-premises CRM system that exposes a REST API with Basic authentication. They want to automate sending welcome emails from Office 365 when a new contact is added. A custom connector is created for the CRM API, using Basic Auth and a Swagger definition that includes the 'CreateContact' action. The Logic App is triggered by an HTTP request from the CRM when a new contact is added (via webhook). The Logic App then calls the custom connector to retrieve contact details and uses the Office 365 Outlook connector to send an email. The solution handles 10,000 contacts per day. Performance considerations: the CRM API has a rate limit of 100 requests per minute, so the Logic App uses a retry policy with exponential backoff and a delay to avoid throttling. Misconfiguration example: if the Swagger definition misses a required parameter, the connector fails at runtime, causing the logic app to retry until it eventually fails permanently.
Enterprise Scenario 2: Exposing a Custom API via API Management
A SaaS provider exposes a custom API for their customers to integrate with. They use Azure API Management (APIM) to manage the API, adding rate limiting and caching. They create a custom connector that points to the APIM endpoint, which then forwards requests to the backend. The custom connector uses OAuth 2.0 with Azure AD. Customers can use this connector in their own Logic Apps. The solution supports 1 million requests per month. Common issues: if the APIM policy changes the request format (e.g., adds a header), the custom connector must be updated to match. Also, the redirect URL for OAuth must be registered in both the custom connector and the Azure AD app.
Enterprise Scenario 3: Internal Tool Automation
An IT department automates provisioning of user accounts in multiple systems (Active Directory, HR system, Slack). They create separate custom connectors for each system. A Logic App triggered by a new hire form (via Microsoft Forms) calls each connector in sequence. The custom connectors use API keys stored in Azure Key Vault. The solution runs 500 times per month. Performance is not critical, but reliability is: if the HR system is down, the logic app should retry and eventually send a notification to IT. Misconfiguration example: if the API key is hardcoded in the connector definition instead of using a connection parameter, the key is exposed in the connector's settings and cannot be rotated without redeploying the connector.
AZ-204 Exam Focus: Logic Apps Connectors and Custom Connectors (Objective 5.1)
The exam tests your ability to create and configure custom connectors, understand authentication options, and troubleshoot common issues. Key areas:
Custom Connector Creation: You must know the steps: define an OpenAPI (Swagger) definition, upload to Azure, configure security, and test. The exam may present a scenario where you need to choose between a custom connector and an HTTP action. Custom connectors are preferred when the API integration is reused across multiple logic apps or when you need to expose a rich set of operations.
Authentication: The three main types are API Key, Basic Auth, and OAuth 2.0. OAuth 2.0 is the most complex; you must know how to configure the authorization endpoint, token endpoint, client ID, client secret, scopes, and redirect URL. The redirect URL format is https://logic-apis-{region}.consent.azure-apim.net/redirect. The exam may ask which authentication type to use for a given scenario (e.g., for a public API with a shared key, use API Key).
Policies: You can add policies to custom connectors to modify HTTP requests and responses. Common policies: Set HTTP header, Set query parameter, Replace string, Validate JWT. The exam may ask what policy to use to add an API key to all requests (Set query parameter or Set HTTP header).
4. Common Wrong Answers: - Using a built-in connector when a custom connector is required: Candidates often think a built-in connector exists for custom APIs, but built-in connectors are only for Microsoft services. - Choosing Basic Auth when OAuth 2.0 is required: Basic Auth sends credentials in plain text; it is not secure for production. The exam expects you to recommend OAuth 2.0 for secure APIs. - Hardcoding API keys in the connector definition: This is a security risk. The correct approach is to use connection parameters that are set at runtime. - Assuming custom connectors are global: They are regional. You must create them in the same region as your logic app.
5. Edge Cases: - Triggers: Custom connectors can define triggers using webhooks or polling. The exam may test that you need to implement a webhook in your API for a trigger to work. - Pagination: If an API returns paginated results, the connector must handle pagination. The exam may ask how to implement pagination (using @pagination in the Swagger definition). - Large responses: If the API returns large payloads (>100 MB), you must store the data in Azure Blob Storage and pass a reference.
Eliminating Wrong Answers: Understand the underlying mechanism: a custom connector is essentially a wrapper that translates the Logic Apps runtime's requests into HTTP calls to your API. If the question involves reusing an API integration across multiple logic apps, the answer is custom connector. If the question involves a simple one-off call to an API, an HTTP action may suffice. Authentication: if the API requires user consent, use OAuth 2.0; if it uses a static key, use API Key.
Memory aids:
Custom connector = Swagger + Auth + Policies
OAuth redirect URL: https://logic-apis-{region}.consent.azure-apim.net/redirect
Default retry: 4 times, exponential backoff starting at 10 seconds
Max message size: 100 MB
Custom connectors require an OpenAPI (Swagger 2.0) definition or a Postman collection v2.1.
Supported authentication types: API Key, Basic Auth, OAuth 2.0, and No Authentication.
Custom connectors are regional; create them in the same region as your logic apps.
OAuth 2.0 redirect URL: https://logic-apis-{region}.consent.azure-apim.net/redirect.
Policies can modify HTTP headers, query parameters, body, and validate JWT tokens.
Default retry policy: 4 retries with exponential backoff (10s, 20s, 40s, 80s).
Maximum message size for Logic Apps actions: 100 MB.
Use custom connectors when you need to reuse an API integration across multiple logic apps.
Custom connectors can define triggers via webhooks or polling; polling interval is configurable.
Test custom connectors in the Azure portal before using them in logic apps.
These come up on the exam all the time. Here's how to tell them apart.
Custom Connector
Provides a Swagger-defined set of operations with input/output schemas.
Supports authentication configuration (API Key, OAuth 2.0, etc.) once, reused across actions.
Can be shared across multiple logic apps in the same region.
Supports policies to modify requests/responses at the connector level.
Requires upfront creation and Swagger definition; more complex to set up.
HTTP Action
Single HTTP request/response action; no predefined operations.
Authentication must be configured per action (e.g., adding headers manually).
Not reusable; each logic app must define its own HTTP action.
No built-in policy support; must use Logic Apps expressions for transformations.
Simple to set up; no Swagger required.
Mistake
Custom connectors can only be used in the logic app where they are created.
Correct
Custom connectors are regional resources that can be used by any logic app in the same Azure region. They are not limited to a single logic app.
Mistake
You can create a custom connector without an OpenAPI definition by using a Postman collection.
Correct
Postman collections are an alternative to OpenAPI definitions. You can upload a Postman collection v2.1, and Azure will generate the OpenAPI definition automatically. Both are acceptable.
Mistake
Custom connectors support all authentication types including Windows Authentication.
Correct
Custom connectors support API Key, Basic Auth, OAuth 2.0, and No Authentication. They do not support Windows Authentication (NTLM/Kerberos) directly. You would need to use an HTTP action with custom authentication.
Mistake
You can modify the underlying API code using policies in a custom connector.
Correct
Policies only modify HTTP requests and responses (headers, query parameters, body). They cannot change the API's logic or behavior. To change the API, you must modify the API code itself.
Mistake
Custom connectors are automatically available globally across all Azure regions.
Correct
Custom connectors are regional. They are created in a specific region and can only be used by logic apps in that region. To use them in multiple regions, you must recreate the connector in each region.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, register your custom connector as an application in Azure AD (or the identity provider). Note the client ID, client secret, and scopes. In the custom connector creation blade, select OAuth 2.0 authentication. Provide the authorization endpoint URL (e.g., https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize), token endpoint URL (e.g., https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token), client ID, client secret, and scopes. The redirect URL is auto-generated and must be added to your app registration's redirect URIs. After creation, test the connector; it will prompt the user to sign in and consent.
Built-in connectors run natively within the Logic Apps runtime and do not require an API connection resource. They are faster and support operations like 'When a HTTP request is received' and 'Call an Azure function'. Managed connectors are hosted by Microsoft and are invoked via a connector infrastructure. They require an API connection resource that stores authentication and connection parameters. Examples: Office 365 Outlook, Salesforce. For the exam, know that built-in connectors are for Azure services and HTTP actions, while managed connectors are for third-party SaaS.
No, custom connectors are regional. They are created in a specific region and can only be used by logic apps in that same region. If you need the same connector in multiple regions, you must create a copy of the custom connector in each region. This is a common exam point: custom connectors are not global.
You can use a policy. In the custom connector's 'Policies' tab, add a policy of type 'Set HTTP header'. Specify the header name and value. The policy will apply to all operations defined in the connector. This is useful for adding API keys or tracing headers. Policies are defined in XML and are applied at the connector level before the request is sent to the API.
By default, Logic Apps will retry the action up to 4 times with exponential backoff. However, if the API returns a Retry-After header, you can configure a custom retry policy that reads that header. Alternatively, you can add a policy in the custom connector to handle 429 responses by implementing a retry-after mechanism. For the exam, know that you can use policies to modify behavior based on HTTP status codes.
Yes. In your OpenAPI definition, you must include a webhook trigger. The definition should specify the webhook URL that the API will call to trigger the logic app. When the logic app is enabled, the custom connector registers a callback URL with the API. When the API sends a POST to that URL, the logic app is triggered. This is more complex than polling triggers and requires the API to support webhooks.
Never hardcode the API key in the connector definition. Instead, use connection parameters. When you create a connection to the custom connector in a logic app, you are prompted to enter the API key. The key is stored securely in the connection resource. For additional security, store the API key in Azure Key Vault and reference it from the logic app using a managed identity.
You've just covered Logic Apps Connectors and Custom Connectors — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?