driveItem invite fails with 400 sharingFailed for every new external recipient since the Entra B2B rollout — SharePoint rejects before the Invitation Manager is called

Question

driveItem invite fails with 400 sharingFailed for every new external recipient since the Entra B2B rollout — SharePoint rejects before the Invitation Manager is called

Paul Mallaband 0

Since the SharePoint/OneDrive transition to Entra B2B (MC1243549, rollout completed

17 July 2026), POST /drives/{drive-id}/items/{item-id}/invite fails for any external

recipient who is not already a guest in the resource tenant.

We have had no successful creation of a new external guest through this API since

8 July 2026 — over 1,200 failures between 24 August and 20 September 2026, across every

customer tenant we integrate with.

Setup. Delegated authentication. The signed-in user is a member of the resource tenant

and owns the OneDrive content being shared. (Not app-only, so the documented "new guests

can't be invited using app-only access" restriction does not apply.)

Request:


POST https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{item-id}/invite

{

  "requireSignIn": true,

  "sendInvitation": false,

  "roles": ["write"],

  "recipients": [{ "email": "<external-recipient>" }]

}

Result:

| Recipient already a redeemed guest in the tenant? | Response |

|---|---|

| Yes | 200 OK |

| No | 400 sharingFailed |


{

  "error": {

    "code": "sharingFailed",

    "message": "There was a problem sharing, please try again later.",

    "innerError": {

      "date": "2026-09-16T13:41:41",

      "request-id": "3165e03a-6ef2-4662-97c6-84109e8ea333",

      "client-request-id": "3165e03a-6ef2-4662-97c6-84109e8ea333"

    }

  }

}

Further failed requests for log correlation:

2026-09-06T11:13:00.767Z — request-id 1b4ded1a-2e88-43a4-969b-660df9087c95 — SPLogId 8c8938a2-1010-3001-304b-f37e9767106a
2026-09-14T15:53:43.242Z — request-id b0d4d82e-06a6-4476-b08b-0959bbac17ae — SPLogId ca2c3ba2-6047-3001-304b-feaad2d2b458
2026-09-16T13:41:41.644Z — request-id 3165e03a-6ef2-4662-97c6-84109e8ea333 — SPLogId 07ca3ba2-f0c0-3001-1afb-e6f0480d58e0

What we have ruled out. Testing on 21–22 September 2026 in our own tenant, with

SharePoint and Entra external sharing settings fully open:

Not the sendInvitation value — fails identically with true and false.
Not our app registration, scopes or SDK — fails identically from Microsoft Graph Explorer.
Not tenant sharing configuration — reproduced with everything open, no domain restrictions, sites active and unlocked.
Not an Entra guest-invite policy refusal — **the Entra audit log shows no "Invite external user" event for these requests at all.** SharePoint appears to reject the request before the Entra B2B Invitation Manager is invoked.

What works on the same tenant, same folder, same recipient:

The OneDrive web UI — succeeds, and the Entra guest is created.
SharePoint REST SP.Web.ShareObject, called from a third-party app with a delegated token — succeeds, and the Entra guest is created. This is the method the web UI itself uses.

So the capability is present and the tenant permits it; it is specifically the Graph

invite path that fails.

Expected behaviour. MC1243549, updated 2 October 2026, states that for new external

users "a guest account will be automatically created via the Entra B2B Invitation Manager

and authentication will use Entra B2B". That is what we observe through the UI and through

ShareObject, and not what we observe through Graph.

Questions:

Is driveItem: invite expected to provision a new external recipient as a B2B guest, as MC1243549 describes and as the UI does? If so, the 400 sharingFailed with no corresponding Entra invitation event looks like a defect in the SharePoint-side handling of this operation.
If it is not expected to, what is the supported route for a delegated third-party application to share with a first-time external recipient? We have moved to SP.Web.ShareObject as a workaround, but would rather depend on a documented Graph path.

Happy to supply further request IDs, tenant IDs by private channel, or run controlled

tests.

0 comments

1 answer

Your answer

Answer 1

Hi Paul,

The report is unusually complete, so I will go straight to the three things I think you are missing rather than repeat what you have already ruled out.

First, and this changes how you should frame the escalation: the API reference does not promise the behaviour you are measuring against. On the driveItem: invite page the only statement about guest provisioning is the negative one, that new guests cannot be invited using app-only access and existing guests can. There is no line anywhere in the delegated section saying that a first-time external recipient gets provisioned as a B2B guest. MC1243549 describes the sharing experience and which authentication stack it uses, not the contract of this endpoint. So "Graph is defective against documented behaviour" is a weaker case than it looks, and support can deflect it. "The web UI and SP.Web.ShareObject provision the guest, Graph does not, and the reference is silent on whether it should" is accurate, harder to close, and it forces either a fix or a documentation statement. Either outcome is useful to you.

Second, there is one test that would make your isolation argument airtight. Call POST https://graph.microsoft.com/v1.0/invitations directly, delegated, same tenant, same recipient, same signed-in user. If that returns 201 and the guest appears in the directory, you have proved the Entra side is healthy and that the failure lives entirely in the call SharePoint makes into the Invitation Manager. Put that next to the absence of any "Invite external user" event in the audit log and you have a two-line reproduction that nobody can attribute to your tenant configuration.

Third, the supported Graph-only route you asked for probably exists, in two steps, and it is better than depending on ShareObject.

Provision the guest first with POST /invitations, then issue the /invite call you already have. Your own results table is the evidence this should work: when the recipient is already a guest in the tenant you get 200 OK. The delegated permission is User.Invite.All, inviteRedirectUrl is required in the body, and sendInvitationMessage can be set to false, so you keep the no-email behaviour you get today from sendInvitation: false. Worth knowing that this does not need an admin role in the normal case. The reference says it plainly:

"Both nonadmin member users and guest users can invite guests if the tenant admin hasn't restricted the default user permissions."

Guest Inviter, Directory Writers or User Administrator are only needed where a tenant has restricted that default, which is worth checking per customer tenant since you work across several.

One caveat I want to be explicit about, because it decides whether this is a fix or just a narrower bug report. Your table proves 200 OK for a recipient who is already a redeemed guest. With sendInvitationMessage set to false the newly created guest sits at PendingAcceptance and has not redeemed. So the case you need to test is /invite against a guest that exists but has not yet redeemed. If that returns 200, the two-step sequence replaces ShareObject entirely and you are done. If it returns 400 sharingFailed as well, then the defect is more specific than you currently describe it, because it would mean SharePoint is failing on redemption state rather than on existence, and that is a much sharper thing to hand to support.

Last thing, and only to save you a detour. There is a separate and currently undocumented problem going around where guest invitations stop working tenant-wide, and it looks superficially similar enough that people get sent down that path. It is not what you have. That one is a 403 from POST /invitations carrying the message "Invitations are blocked for this directory due to suspicious activity", it begins only after a number of successful invitations somewhere between eight and eleven, and it affects the Entra invitation path itself. Yours is a 400 sharingFailed from the very first attempt, on every tenant, with the Entra path apparently untouched. Different failure, different layer. If the POST /invitations test in step two comes back 201, you can also stop worrying about that one entirely.

If you do run that test, I would be interested in the result, since the redemption-state question above is the part that is genuinely unknown.