Review Request Invite Endpoint

We are integrating with the review-request invite endpoint:

POST /api/v1/request-reviews/campaigns/{campaign}/invite

We need clarification on correlation and read-only reconciliation behavior so that we can safely handle an HTTP response being lost without accidentally creating a duplicate invite.

Could you please confirm the following?

1. What exact resource does the id returned in a successful 202 Accepted invite response identify?

2. Is that ID unique and stable for one specific invite/request? If so, what is its uniqueness scope—for example globally, per account, per campaign, or per contact?

3. When the API returns 202 for a contact that is silently ignored because of the campaign deduplication window, what does the returned id represent?

4. When an invite is queued because it falls outside the campaign send window, what does the returned id represent?

5. Is there a supported read-only REST API endpoint that can later retrieve the specific invite/request using that ID? If so, could you provide the method, route, required permissions, and response/status fields?

6. Can that lookup distinguish states such as accepted, queued, processing, sent, failed/rejected, and delivered? Please clarify the exact semantics of any statuses returned.

7. Does the REST invite endpoint support a caller-generated idempotency key, correlation ID, external reference, client request ID, custom metadata value, or similar identifier that EmbedMyReviews persists and can later return or query?

8. We saw X-Correlation-Id documented for the MCP endpoint. Does that header—or any equivalent correlation mechanism—also apply to the REST invite endpoint? If so, is it persisted with the resulting invite and available for later lookup?

9. Critical failure scenario: suppose our system submits one valid invite, EmbedMyReviews receives/processes it, but the HTTP connection fails before we receive the response and therefore we never learn the returned id. Is there any supported authoritative method to locate that exact request later without submitting another invite and without matching heuristically by email, phone, campaign, or timestamp?

10. Are there webhook events for individual review-request invite creation, queueing, sending, failure, or delivery? If so, what stable identifier links those webhook events back to the original invite API request?

11. If an individual invite/status lookup API is not publicly documented, is such a capability available privately, in another API version, or planned?

12. If a lookup returns “not found,” what guarantees—if any—does that provide? In particular, are there retention, indexing-delay, or visibility limitations that would mean “not found” does not prove that the original invite was never accepted?

Our objective is read-only reconciliation only. We are specifically trying to avoid duplicate sends after ambiguous network failures, and we will not interpret a missing record or lookup failure as permission to resend.

No customer or production-identifying data is needed for this clarification.