Skip to main content
Analyze documents with a custom-trained model in Azure Document Intelligence. This guide covers the authentication and request pattern needed to run a deployed custom model and retrieve the structured results returned by the service. Key workflow summary:
  • Provide the Document Intelligence resource endpoint and an access key to authenticate API calls.
  • Include the deployed custom model’s ID in the analysis request so the service knows which model to execute.
  • The service returns a poller object for long-running analysis operations; use it to monitor progress and obtain the final AnalyzeResult once processing completes.
A presentation slide titled "Analyzing Documents Using Custom Model" showing three numbered steps about needing an endpoint and key, including the deployed model ID in requests, and querying the poller to retrieve processed data. The design uses a dark blue background with teal accent bars and numbering.
Before calling the SDK, confirm your custom model is deployed and take note of the model ID. Ensure the document URI is reachable by the service (public URL or storage with proper access). If you use SAS-secured blobs, verify the token grants read access to the file.
Below are example usage patterns for the SDKs. The primary difference from built-in models is that you explicitly pass your custom model’s ID when starting the analysis so the service can run the correct trained model. C# example (async, using DocumentAnalysisClient)
Python example (poller)
Common SDK method mapping
Be careful with secrets and endpoint values. Never check your Azure keys into source control. If using storage URIs with tokens, ensure the token provides read access and is valid for the duration of the analysis.
Inspecting results
  • Once the poller completes, the returned AnalyzeResult (C#) or result (Python) contains:
    • Extracted fields as defined by your custom model (names, values, and confidence scores).
    • Page and layout information (text lines, bounding regions).
    • Additional metadata such as page ranges and any warnings produced during processing.
  • Use these fields to populate downstream processes, persist structured data, or drive business logic that depends on the extracted content.
Links and references

Watch Video