GraphWarden compatibility statement (template)

**This page is a template.** Everything inside the "Template body" section below is the copy-paste payload. Replace the `{curly brace}` markers with your product details, then publish the body on your own documentation site under a title like "{Product name} compatibility with GraphWarden".
Copy-paste template

Template body (copy from here)

{Product name} and GraphWarden

{Product name} version {Minimum version} and later integrates with GraphWarden by routing Microsoft Graph API calls through the proxy you configure. Customers who run GraphWarden can deploy {Product name} without a code change: they point {Product name}'s Graph endpoint configuration at their GraphWarden proxy URL and provide the proxy credentials from their GraphWarden administration console.

How the integration works

  1. Your GraphWarden administrator creates an App Identity for {Product name} and generates proxy credentials (a Proxy Client ID and a Proxy Client Secret).
  2. Your GraphWarden administrator configures a ruleset specifying which Microsoft Graph endpoints and scopes {Product name} may access.
  3. You configure {Product name} with:
    • Graph base URL: your GraphWarden proxy URL (in place of https://graph.microsoft.com)
    • Graph client ID: the Proxy Client ID from your GraphWarden administration console
    • Graph client secret: the Proxy Client Secret from your GraphWarden administration console
  4. {Product name} calls Microsoft Graph through your proxy. Your GraphWarden installation audits every call and enforces your ruleset.

Supported Microsoft Graph endpoints

{Supported Graph endpoints}

Known limitations

{Known limitations}

Customer responsibilities

You are responsible for:

  • Configuring your GraphWarden ruleset to permit the Graph endpoints {Product name} requires (see the endpoint list above).
  • Rotating proxy credentials per your GraphWarden administration policy.
  • Monitoring GraphWarden audit logs for denied calls that indicate a ruleset mismatch with {Product name}'s needs.

Support

For issues specific to {Product name}, contact {Contact email}. For issues specific to GraphWarden (proxy unavailability, ruleset denials, audit log access), contact your GraphWarden administrator.

Template ends here

Customization checklist

Before publishing your customized statement, work through the checklist below.

  • Replace {Product name} throughout the body (appears roughly six times).
  • Replace {Minimum version} with the earliest product version that reads the Graph base URL and credentials from configuration.
  • Replace {Supported Graph endpoints} with the exact Graph paths and methods your product calls.
  • Replace {Known limitations} with any edge cases specific to your product — subscription endpoints, webhooks, beta endpoints, and similar.
  • Replace {Contact email} with your product support address.
  • Remove the Customization checklist section from the published copy.
  • Remove the meta-note callout at the top of this page from the published copy.
  • Keep the Customer responsibilities section — it sets accurate expectations and prevents support tickets that belong to the administrator.
  • Add a last-updated date to the published statement so customers can tell when the document was last reviewed against your product.

Troubleshooting

The three scenarios below cover the questions your support team receives most often once the compatibility statement is live.

"The proxy URL returns 401."

The customer configured their Graph credentials, not the proxy credentials, in {Product name}. The proxy issues a distinct Proxy Client ID and Proxy Client Secret pair, separate from the Azure AD application credentials. Direct the customer to their GraphWarden administrator to re-issue the proxy pair and confirm which input field in {Product name} accepts the proxy credentials.

"Some features work, others return 403."

The customer's GraphWarden ruleset permits some endpoints and denies others. Each 403 response names the matched rule id; direct the customer to their GraphWarden administrator with the rule id to adjust the ruleset. This is expected behaviour — the administrator's ruleset is the authoritative source for which Graph endpoints are permitted.

"The integration worked in direct-Graph mode but not with GraphWarden."

Confirm {Product name} reads the Graph base URL from configuration rather than a hardcoded constant. If the base URL is hardcoded in {Product name}'s source, the product cannot route through GraphWarden. This indicates a product issue, not a GraphWarden configuration issue, and your engineering team should externalize the constant in the next release.

"Audit logs show calls to /subscriptions being blocked."

If your product relies on Graph subscriptions and webhooks, those calls may bypass GraphWarden by design (the webhook delivery path originates from Microsoft, not from your product). The customer should be aware this traffic does not appear in GraphWarden audit logs. Document this under Known limitations in your published statement.

Last reviewed:

Last reviewed: .