Designing a webhook + polling architecture for an existing OAuth-based integration. The polling layer is intended to serve customers whose application servers cannot expose a public webhook URL (private IP, VPN-only access). Five questions where the docs aren't conclusive:

1. MOPI scope on GET /agreements (the list endpoint)

The Minimum Object Polling Interval policy applies to "all GET API endpoints." For GET /agreements/{agreementId} the polled object is clear. For the list endpoint GET /agreements (no path ID, returns a paginated list), it's not.

Two plausible interpretations:

1. The list itself is a single polled object. Calling GET /agreements more than once per 10-minute window (non-Enterprise) or 3 times per minute (Enterprise) returns 429 / 304.
2. Each agreement in the response is the polled object. Successive calls to GET /agreements are unrestricted as long as the same agreement isn't returned more frequently than allowed.

Which is correct? This determines whether GET /agreements is viable as a 60-second-cadence bulk-status polling endpoint.

2. Is POST /v6/search subject to MOPI?

MOPI guidance specifies "all GET API endpoints," which would seem to exclude POST /v6/search. The older documented search rate limits (1,000/min, 2,500/hr, 7,200/day) appear to still apply.

• Is POST /v6/search exempt from MOPI?
• Are the older search-specific rate limits still current as of the May 2026 release?
• Is search-with-modifiedDate-filter a supported pattern for polling account-wide status changes?

3. POST /v6/search tier availability

Is POST /v6/search available across all Acrobat Sign account tiers (Individual, Team, Business, Enterprise, Government, Developer)? Or is it gated to specific tiers?

4. Account-scoped webhook — required OAuth scopes

Switching from per-agreement webhooks to a single account-scoped webhook registered at OAuth-connect time:

POST /api/rest/v6/webhooks
{
  "scope": "ACCOUNT",
  "state": "ACTIVE",
  "webhookUrlInfo": { "url": "<handler>" },
  "webhookSubscriptionEvents": [ ... ]
}

• Any required OAuth scope beyond webhook_read / webhook_write / webhook_retention?
• Are any events restricted to specific scope levels, or are all agreement events available at ACCOUNT scope?
• Does the registering user need to be an account administrator, or is any user with the right OAuth grants sufficient?

5. "Polling as recovery" — intended scope

The Acrobat Sign Events guide recommends:

"It is also recommended to set up some sort of 'polling' mechanism and some way to re-create these 'per-agreement' webhooks if the creation step has failed."

For customers whose network configuration permanently blocks webhook delivery, "webhook creation has failed" isn't a transient retry case — it's the permanent operational mode.

Is the polling-as-recovery pattern intended only for transient webhook-creation failures, or does Adobe consider it acceptable as the ongoing primary mechanism in that scenario? If not, is there a different Adobe-supported architecture (event journal, I/O Events stream, Adobe-hosted relay) for customers whose infrastructure permanently blocks public webhook delivery?