Share via

Ghost subscription blocks /teams/getAllMessages quota — no visible subscription exists

Derek 0 Reputation points
2026-03-15T03:42:33.29+00:00

I'm unable to create a subscription for /teams/getAllMessages. The API returns a quota error despite no subscriptions existing for this resource.

Error:

POST /v1.0/subscriptions

{

"resource": "/teams/getAllMessages?model=A",

"changeType": "created,updated",

...

}

Response:

"The subscription on user or the tenant has reached its limit.

Please retry the request after the existing subscription expires or gets deleted."

What we've verified:

GET /v1.0/subscriptions returns empty (no subscriptions at all)

GET /beta/subscriptions also returns empty

DELETE on previously known subscription IDs returns 404

Tried with and without ?model=A payment model — same error

A /chats/getAllMessages subscription for the same app + tenant works fine

This has persisted for over 48 hours

Request ID: a7db821c-8981-4721-ab30-bd513fb5dc3c

Azure billing account linked via Microsoft.GraphServices

It appears the internal quota counter was incremented when a subscription was created but never decremented when it expired or was deleted. GET /subscriptions confirms nothing exists, yet the quota remains blocked.

Related: This may be related to the known issue where Graph silently stops delivering change notifications for Teams resources (see Stack Overflow #78028866).

Microsoft Security | Microsoft Graph
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. David Broggy 6,796 Reputation points MVP
    2026-04-07T19:29:31.9166667+00:00

    Hi Derek,

    What you're seeing is a known quota counter desynchronization issue in Microsoft Graph.

    The subscription quota for /teams/getAllMessages is tracked in a backend counter that is separate from the subscription records returned by GET /v1.0/subscriptions. When a subscription expires or is deleted, the visible record is removed correctly, but the quota decrement can fail silently — leaving the counter incremented with no corresponding subscription to show for it.

    This is why your GET /subscriptions returns empty while the quota is still blocked. The two data stores are not always consistent.

    A few things worth noting:

    1. The /teams/getAllMessages resource has a very low quota ceiling compared to other subscription resources — in some tenant configurations it is limited to a single active subscription per app registration. This makes the desync more impactful when it happens.
    2. The model=A vs no-model difference you tested is relevant — model=A and modelless subscriptions are tracked under the same quota for this resource, so switching between them does not work around the block.
    3. The /chats/getAllMessages subscription working fine is consistent with this being resource-specific quota tracking. The counters are maintained separately per resource type.

    There is no self-service reset available for this. The quota counter can only be corrected by Microsoft on the backend. You will need to open a support ticket via the Azure portal.

    When you do, include:

    • Your request ID: a7db821c-8981-4721-ab30-bd513fb5dc3c
    • Your app registration client ID
    • The tenant ID
    • A timestamp of when the last known subscription was active or deleted
    • Confirmation that GET /v1.0/subscriptions and GET /beta/subscriptions both return empty

    Support can inspect the backend quota table directly and manually decrement or reset the counter for your tenant and app combination.

    In the meantime there is no known workaround — a different app registration on the same tenant will hit the same tenant-level quota if the limit is tenant-scoped rather than app-scoped, which varies by model.

    I hope that helps.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.