.png)
Azure AI Search Integration Guide
Connect enterprise applications and content sources to Azure AI Search through REST APIs, batch indexing, indexers, and controlled search workflows.
Azure AI Search integration options at a glance
Azure AI Search provides REST APIs for managing indexes, documents, indexers, data sources, skillsets, synonym maps, aliases, and search queries. Applications can submit keyword, semantic, vector, and hybrid searches, while batch indexing supports upload, merge, merge-or-upload, and delete actions. Indexers can pull content from supported sources such as Azure Blob Storage, Azure SQL Database, Azure Cosmos DB, and Azure Table Storage. Authentication uses API keys or Microsoft Entra ID with Azure RBAC. Martini can consume these APIs, expose a normalized search API, schedule synchronization workflows, transform source data, process batch results, and use upstream events for selected near-real-time index updates.
| Integration point | Supported by Azure AI Search? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage indexes, documents, indexers, data sources, skillsets, synonym maps, aliases, and keyword, semantic, vector, or hybrid queries. | Martini can consume Azure AI Search REST endpoints from workflows and expose APIs that normalize Azure-specific request and response models. |
| Bulk / batch indexing APIs | Yes | Upload, merge, merge-or-upload, and delete documents in batches while loading or updating an index. | Martini can construct batches, enforce payload and action limits, inspect per-document results, and route failed actions for retry or dead-letter processing. |
| Indexers and scheduled ingestion | Yes | Pull content from supported data sources and populate indexes on a schedule or through API invocation. | Martini can invoke indexers, retrieve status, supplement them with custom workflows, or implement source-specific synchronization when indexer behavior is insufficient. |
| Semantic, vector, and hybrid search | Yes | Execute semantic ranking, vector similarity, keyword, filtered, faceted, sorted, and combined hybrid searches. | Martini can map a normalized search request to the appropriate Azure query parameters and return a consistent enterprise response. |
| File / attachment ingestion | Limited | Index supported files and content through Azure Blob Storage integration and enrichment pipelines; Azure AI Search is not a general attachment repository. | Martini can coordinate file metadata, source filtering, enrichment inputs, and subsequent indexing while leaving binary storage to the appropriate source system. |
| Database source integration | Limited | Use supported source indexers, such as Azure SQL Database or Azure Cosmos DB scenarios, to populate search indexes; Azure AI Search does not expose general SQL access to index contents. | Martini can access source databases separately, apply custom transformations, and submit documents through the Azure AI Search REST API. |
| Webhooks / outbound callbacks | Limited | Azure AI Search does not provide universal outbound webhooks for every search, index, or document event; indexers are scheduled or API-invoked. | Martini can receive upstream storage or messaging events and use them to trigger index updates, without representing Azure AI Search itself as a universal webhook source. |
| Authentication | Yes | Authenticate with admin or query API keys, or with Microsoft Entra ID bearer tokens and Azure RBAC roles. | Martini can keep endpoints and credentials in secure environment configuration and secrets, using the least-privileged authentication model appropriate to the workflow. |
| SDKs | Yes | Microsoft SDKs are available for .NET, Java, JavaScript, and Python when application code prefers an SDK over direct REST calls. | Martini can generally use the REST API directly and can extend workflows with custom JVM-compatible logic only when required. |
How Azure AI Search exposes data and business events
Azure AI Search REST APIs
Azure AI Search REST APIs provide the principal integration surface for managing indexes, documents, queries, indexers, data sources, skillsets, synonym maps, aliases, and service-related operations. Search requests can use keyword, semantic, vector, or hybrid query models.
Martini implementation pattern
Martini implementation pattern: expose or receive an application request, validate the model, map it to the selected Azure AI Search API version and query shape, invoke the endpoint with secured authentication, normalize the response, and return or route the result.
Implementation sequence
Batch document indexing
The document indexing API supports upload, merge, merge-or-upload, and delete actions in batches. Responses can include status information for individual documents, so a successful HTTP response does not necessarily mean every action succeeded.
Martini implementation pattern
Martini implementation pattern: transform source objects into Azure AI Search documents, create bounded batches, submit them, inspect each action result, and route transient or permanent failures separately while preserving stable document keys.
Implementation sequence
Azure AI Search indexers
Indexers pull content from supported data sources such as Azure Blob Storage, Azure SQL Database, Azure Cosmos DB, and Azure Table Storage. They can run on schedules or be invoked through APIs and may use source-side change detection or high-water-mark tracking.
Martini implementation pattern
Martini implementation pattern: invoke an indexer when required, monitor its status, and supplement it with a Martini-managed workflow when custom filtering, enrichment, cross-system rules, or more direct update timing is needed.
Implementation sequence
Upstream event-driven indexing
Azure AI Search does not generally emit outbound webhooks for all document or index changes. Event-driven updates therefore originate from upstream systems such as Azure Storage events, Azure Event Grid, or messaging platforms and then update Azure AI Search through its APIs.
Martini implementation pattern
Martini implementation pattern: receive an upstream event, retrieve the authoritative source object, determine whether the action is upload, merge, merge-or-upload, or delete, and submit the resulting document action to Azure AI Search.
Implementation sequence
Semantic, vector, and hybrid queries
Azure AI Search supports full-text keyword queries, semantic ranking, vector search, and hybrid combinations with filters, facets, sorting, and scoring profiles. These query modes have different request shapes and response metadata.
Martini implementation pattern
Martini implementation pattern: provide a stable enterprise search contract, select the Azure query mode based on request attributes, map filters and ranking options, and normalize results so consuming applications are not tightly coupled to Azure-specific fields.
Implementation sequence
Common Azure AI Search integration patterns
Pattern 1: Expose a unified enterprise search API
When to use this pattern
Use this pattern when multiple portals, applications, or business channels need search without each client implementing Azure AI Search query syntax. It is suitable for standardizing authorization, query modes, filters, response fields, and diagnostics.
Integration direction
Example Mapping
| Azure AI Search Field | Canonical Field | Target Field |
|---|---|---|
| searchText | query.text | search |
| searchMode | query.retrievalMode | queryType / vectorQueries |
| filters | query.filters | filter |
| pageSize | query.pageSize | top |
Martini implementation pattern
A Martini REST API validates the incoming request, applies business rules, selects keyword, semantic, vector, or hybrid search, maps the request to Azure AI Search parameters, invokes the query endpoint, and returns a normalized response. Authorization failures, invalid query models, throttling, and transient errors are handled distinctly.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Synchronize source content into an index
When to use this pattern
Use this pattern when content from Azure SQL Database, Azure Blob Storage, Azure Cosmos DB, or another source requires custom filtering, transformation, enrichment, or cross-system coordination before indexing.
Integration direction
Example Mapping
| Azure AI Search Field | Canonical Field | Target Field |
|---|---|---|
| sourceId | document.id | key |
| title | document.title | title |
| body | document.content | content |
| updatedAt | document.sourceModifiedAt | sourceModifiedAt |
Martini implementation pattern
A scheduled or source-triggered Martini workflow retrieves changed content, validates source identifiers, transforms fields and metadata, applies inclusion rules, creates upload or merge-or-upload actions, and submits bounded batches. It stores checkpoints and routes failed documents with their source keys for retry.
Martini capabilities used
- scheduled workflows
- API consumption
- mapping and transformation
- validation
- batch orchestration
- retry and error handling
Pattern 3: Process event-driven index updates
When to use this pattern
Use this pattern when an upstream storage or messaging system can reliably publish content-change events and the business requires faster updates than a periodic indexer schedule provides. Azure AI Search itself is not treated as the webhook source.
Integration direction
Example Mapping
| Azure AI Search Field | Canonical Field | Target Field |
|---|---|---|
| event.subject | source.objectId | key |
| event.eventType | change.action | upload / merge / delete |
| event.data.url | source.location | document source |
| event.id | processing.eventId | workflow deduplication key |
Martini implementation pattern
Martini receives and validates the upstream event, deduplicates it, retrieves the authoritative source object, determines the required indexing action, and calls Azure AI Search. Transient service failures are retried while malformed events, missing sources, and authorization failures are routed for investigation.
Martini capabilities used
- event triggers
- workflows
- API consumption
- business rules
- deduplication
- error handling
Pattern 4: Rebuild and cut over an index version
When to use this pattern
Use this pattern when changes to field definitions, searchable attributes, vector configuration, or enrichment behavior require a controlled reindex rather than an in-place change.
Integration direction
Example Mapping
| Azure AI Search Field | Canonical Field | Target Field |
|---|---|---|
| indexSchemaVersion | deployment.indexVersion | new index name |
| sourceId | document.id | key |
| documentPayload | document.body | new index document |
| validationStatus | deployment.readiness | alias cutover decision |
Martini implementation pattern
Martini creates or prepares the new index version, loads documents in batches, evaluates per-document results and representative search checks, and updates an alias or controlled consumer configuration only after validation. Failed loads stop or quarantine the cutover according to deployment rules.
Martini capabilities used
- workflows
- API orchestration
- mapping
- validation
- deployment coordination
- monitoring
Applications commonly integrated with Azure AI Search
Azure AI Search commonly participates in Microsoft-centric content and data architectures, as well as application-specific search experiences. Martini can coordinate source retrieval, transformation, indexing, query normalization, and error handling without requiring every consuming application to implement Azure-specific API behavior.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Azure Blob Storage | Index documents, PDFs, office files, and other supported content stored in Blob Storage. | Azure Blob Storage → Azure AI Search | Use an Azure AI Search Blob indexer for supported pull-based ingestion, or use a Martini workflow when custom filtering, enrichment, routing, or source-side business rules are required. |
| Azure SQL Database | Make relational business data searchable through an Azure AI Search index. | Azure SQL Database → Martini → Azure AI Search | Retrieve changed source data through a database integration or use an Azure AI Search SQL indexer, then map stable identifiers and business fields into batch indexing actions. |
| Azure Cosmos DB | Index JSON documents and application content stored in Cosmos DB. | Azure Cosmos DB → Azure AI Search | Use the supported Cosmos DB indexer where its change detection and schema behavior are sufficient; otherwise, let Martini retrieve, validate, transform, and submit document batches through the REST API. |
| Azure Data Lake Storage Gen2 | Make selected data-lake files and content available through an enriched search index. | Azure Data Lake Storage Gen2 → Azure AI Search | Coordinate source selection and metadata enrichment in Martini, then invoke Azure AI Search indexing or rely on the applicable storage indexing capability for supported content. |
| SharePoint Online | Provide search over organizational documents and collaboration content where the applicable Microsoft indexing capability is enabled. | SharePoint Online → Azure AI Search | Use the applicable documented SharePoint indexing approach and place Martini in front of search or enrichment operations when a normalized API, access policy, or additional transformation is needed. |
| Microsoft Power Apps | Add Azure AI Search capabilities to business applications without exposing Azure-specific query models directly to each app. | Microsoft Power Apps → Martini → Azure AI Search | Expose a Martini REST API, validate and normalize the application request, translate keyword, semantic, vector, or hybrid options, and return a stable response model. |
| Microsoft Teams | Support search over selected knowledge or content used by Teams-based applications and bots. | Microsoft Teams → Martini → Azure AI Search | Use a Martini API as a controlled search façade, applying authorization, query normalization, response shaping, and correlation logging before calling Azure AI Search. |
| Azure OpenAI Service | Support retrieval-augmented generation workflows using content retrieved from Azure AI Search. | Azure AI Search → Martini → Azure OpenAI Service | Retrieve relevant Azure AI Search results, apply filtering and response normalization in a Martini workflow, and pass the selected context to the application or Azure OpenAI orchestration layer. |
How to build a Azure AI Search integration in Martini
Objective
Configure the Azure AI Search service endpoint and select an authentication model appropriate to the operation, preferably Microsoft Entra ID with scoped Azure RBAC for managed service-to-service access.
Instructions in Martini
- Set the service endpoint and API version as environment configuration
- Store API keys, client secrets, and tenant details in secure secrets management
- Use query keys only for narrowly scoped read-only search where appropriate
- Assign only the Azure RBAC role required by the workflow
Objective
Select a REST API request, schedule, indexer invocation, or upstream content event based on the required freshness and source behavior.
Instructions in Martini
- Use an API trigger for synchronous search or management operations
- Use a scheduler for periodic synchronization or indexer monitoring
- Receive upstream events only when the source system provides a reliable event mechanism
- Do not model Azure AI Search as a universal outbound webhook source
Objective
Obtain the authoritative source content or application search request before calling Azure AI Search.
Instructions in Martini
- Retrieve changed source objects using the applicable API or database integration
- Use source timestamps or change tokens where available
- For search, validate the incoming query and requested retrieval mode
- Preserve source identifiers and workflow correlation data
Objective
Coordinate validation, API calls, conditional routing, batching, status checks, and response handling in a maintainable Martini workflow.
Instructions in Martini
- Separate query, indexing, indexer, and deployment operations into clear workflow paths
- Apply conditional logic for upload, merge, merge-or-upload, and delete actions
- Keep API version and index configuration externalized
- Use reusable services or workflow components for common Azure calls
Objective
Convert source objects and application requests into Azure AI Search models while preserving stable keys and required metadata.
Instructions in Martini
- Map source identifiers to compliant Azure AI Search document keys
- Transform content, metadata, filters, and query parameters
- Construct bounded indexing batches
- Normalize Azure responses when exposing a shared enterprise API
Objective
Control which content is indexed, which users can search it, and when an index version is ready for use.
Instructions in Martini
- Validate required fields and reject invalid document actions
- Apply inclusion, redaction, routing, and enrichment rules
- Distinguish semantic, vector, hybrid, and keyword query behavior
- Require validation before alias or consumer cutover
Common Azure AI Search data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Indexes | Define searchable, filterable, sortable, facetable, vector, and other field behavior for a search collection. | Enterprise applications, portals, knowledge platforms, deployment pipelines | Martini can create or update indexes through REST workflows, validate schema inputs, and coordinate versioned index deployment or alias changes. |
| Documents | Store JSON content that can be searched, filtered, ranked, and returned to applications. | Azure AI Search indexes, portals, Power Apps, Teams applications, retrieval workflows | Martini maps source objects to document payloads, assigns stable keys, submits upload or merge actions, and processes per-document results. |
| Indexers | Pull supported source content into an index on a schedule or through an API invocation. | Azure Blob Storage, Azure SQL Database, Azure Cosmos DB, Azure Table Storage | Martini can invoke indexers, inspect status, and choose a custom synchronization workflow when additional transformation or business rules are needed. |
| Data sources | Define source connection information used by Azure AI Search indexers. | Azure Blob Storage, Azure SQL Database, Azure Cosmos DB, Azure Table Storage | Martini can manage or reference data-source configuration through secured API workflows and keep source credentials outside payloads. |
| Skillsets | Apply built-in or custom enrichment skills while content is being indexed. | Document-processing pipelines, enriched Azure AI Search indexes | Martini can orchestrate skillset-related configuration and prepare source metadata or enrichment inputs where the integration requires external control. |
| Aliases | Provide an alternate index name for controlled index version changes and consumer cutovers. | Search APIs, application configuration, deployment workflows | Martini can coordinate creation, loading, validation, and alias updates as part of a managed reindexing workflow. |
Authentication and security considerations
Authentication options
Azure AI Search supports admin and query API keys as well as Microsoft Entra ID bearer tokens with Azure RBAC. Prefer Microsoft Entra ID and narrowly scoped roles for managed enterprise service-to-service integrations. Query keys are appropriate for limited read-only search access, while admin keys should be reserved for management and indexing operations.
Martini security model
Martini can keep service endpoints, API keys, client secrets, tenant identifiers, and API versions in secure environment configuration and secrets management rather than workflow payloads. Apply least privilege and avoid exposing administrative credentials through user-facing APIs.
Operational considerations for Azure AI Search integrations
API versions and limits
Keep Azure AI Search API versions configurable because operations and features can have version-specific behavior. Observe search result limits, pagination behavior, indexing batch limits, payload constraints, and throttling responses.
Reliability and idempotency
- Use stable source identifiers as Azure AI Search document keys.
- Inspect individual batch action results and route partial failures separately.
- Retry transient network, throttling, and service-availability failures, but do not blindly retry malformed requests or authorization failures.
- Deduplicate upstream events and preserve workflow correlation identifiers.
Schema and indexer behavior
Changes to field types and searchable, filterable, sortable, or vector properties may require a new index. Use controlled reindexing and aliases where appropriate. Indexers are pull-based and depend on source permissions, schedules, and change-detection behavior; they may not reflect every source update immediately.
Testing and monitoring
Test representative keyword, semantic, vector, and hybrid queries, document mappings, key encoding, partial failures, and schema changes. Monitor indexer status, indexing lag, failed documents, throttling, Azure request identifiers, and Martini workflow logs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond direct API calls
Direct scripts can call Azure AI Search, but they commonly leave authentication, mapping, retries, checkpoints, and operational visibility embedded in application-specific code. Martini centralizes these concerns in workflows and reusable integration assets.
Controlled APIs and reusable models
Martini can expose a stable search API that hides Azure-specific query parameters from consuming applications. It can also transform source-system objects into consistent document models and route different indexing or search modes through governed business rules.
Maintainable operations
- Use scheduled, API-driven, or upstream event-triggered workflows.
- Keep secrets and environment-specific endpoints outside workflow payloads.
- Handle batch partial failures, retries, deduplication, and dead-letter routing consistently.
- Coordinate index rebuilds, validation, aliases, and controlled deployment changes.
Frequently asked questions
Azure AI Search can be integrated through its REST APIs, batch document indexing APIs, scheduled or API-invoked indexers, and supported source integrations. Enterprise applications can use keyword, semantic, vector, and hybrid search, while upstream events can trigger workflows that update indexes.
Yes. Martini can consume Azure AI Search REST APIs from workflows, expose a controlled search API, map application requests, transform source objects into document batches, invoke indexers, and handle per-document results and retries. No native Martini connector is confirmed in the supplied research.
No. A dedicated Azure AI Search connector is not required. Martini can use Azure AI Search's native REST APIs, batch indexing operations, indexer controls, API-key or Microsoft Entra authentication, and upstream event sources where applicable.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Azure AI Search. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Azure, infrastructure, network services, Azure OpenAI Service, storage, or other third-party systems.
Use the REST APIs for indexes, documents, queries, indexers, data sources, skillsets, synonym maps, and aliases. Use batch indexing for document loads and updates, indexers for supported pull-based sources, and a Martini-managed workflow when custom transformation, routing, or business rules are needed. Azure AI Search does not have a confirmed native GraphQL or SOAP API.
Azure AI Search does not generally provide universal outbound webhooks for every search, index, or document event. Indexers can run on schedules or through API invocation. For event-driven updates, Martini can receive upstream storage, Event Grid, or messaging events and then update Azure AI Search.
Martini can run scheduled or event-triggered workflows that retrieve changed source objects, map them to Azure AI Search document fields, apply validation and business rules, and submit upload, merge, merge-or-upload, or delete actions. Stable document keys and checkpoints help make retries idempotent.
A robust workflow inspects per-document indexing results rather than relying only on the HTTP status. Martini can retry transient network, throttling, and service-availability failures, route permanent failures for review, preserve source identifiers and correlation data, and use stable document keys to prevent duplicate logical documents. Martini can also expose a normalized API façade for search.
Related Martini documentation
Build reliable Azure AI Search integrations with Martini
Use Martini to connect Azure AI Search with enterprise applications, data sources, and event-driven workflows through governed APIs, secure configuration, transformation, and operational controls.