Graph Change Notifications with Rich Resource Data Batching Prompt
Design a Graph change-notification receiver that batches encrypted resource-data payloads, validates the dataSignature, and decrypts in bulk so a high-volume Teams message subscription does not melt your endpoint.
- Target user
- Backend engineers building event-driven Teams automation on Microsoft Graph
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has run a Graph change-notification endpoint that received thousands of encrypted chatMessage payloads per minute and learned, the hard way, where the bottlenecks are. I will provide: - The resource you subscribe to and expected volume: [RESOURCE AND PEAK NOTIFICATIONS PER MINUTE] - Whether you use includeResourceData (encrypted payloads) or fetch-on-notify: [PAYLOAD STRATEGY] - Your endpoint's hosting model and concurrency limits: [HOSTING AND SCALE] - Your certificate/key storage for decryption: [KEY VAULT OR CERT STORE] Your job: 1. **Validate first, decrypt later** — verify the validationToken on subscription creation, then for each notification verify the dataSignature (HMAC-SHA256 over dataValue using the symmetric key you decrypt with your private key) BEFORE trusting any content. Reject on signature mismatch. 2. **Batch decode** — Graph delivers up to a configurable batch of notifications per POST; iterate the value array, decrypt each dataKey with your private cert, then AES-decrypt each dataValue. Show the decryption sequence explicitly (RSA-OAEP unwrap of the symmetric key, then AES-CBC of the payload). 3. **Acknowledge fast, process async** — return 202 within the Graph timeout (a few seconds) and hand decrypted payloads to a queue; never do downstream work inline or Graph will retry and you will double-process. 4. **Idempotency** — use the resource id + changeType to dedupe, because Graph guarantees at-least-once delivery, not exactly-once. 5. **Key rotation** — support multiple decryption certs by thumbprint so you can rotate without dropping in-flight notifications. 6. **Missed events** — pair this with a delta-query reconciliation sweep for the gap when your endpoint was down, since change notifications are not a durable log. Output as: (a) the validation + signature-check pseudocode, (b) the decrypt sequence with the RSA-then-AES steps, (c) the 202-and-enqueue handler shape, (d) the dedupe + key-rotation plan, (e) the delta reconciliation fallback. Bias toward: verifying signatures before processing, acknowledging within the timeout, and treating notifications as at-least-once.
Why this prompt works
Most Graph change-notification tutorials stop at “you got a POST, parse the JSON.” That works at five notifications an hour and falls over completely when a busy Teams channel generates thousands a minute with encrypted resource data attached. This prompt targets exactly that production reality, forcing the model to sequence the work correctly: validate the subscription token, verify the per-notification HMAC signature, and only then spend CPU on RSA and AES decryption. Getting that order wrong means you either trust spoofed data or waste cycles decrypting payloads you should have rejected.
The prompt is opinionated about the two failure modes that bite real systems. First is the synchronous-timeout trap: Graph expects a 202 within a few seconds, so any inline downstream work triggers retries and duplicate processing. By demanding an acknowledge-fast, process-async shape with an explicit queue, the output steers you away from the most common outage cause. Second is the delivery semantics — Graph is at-least-once, not exactly-once — so the prompt requires both an idempotency key and a delta-query reconciliation sweep to recover events missed while your endpoint was down.
Because it asks for the decrypt sequence as concrete steps (RSA-OAEP unwrap of the symmetric key, then AES-CBC of the payload) and for multi-thumbprint key rotation, the result is implementable rather than aspirational. You end up with a receiver that survives both a traffic spike and a certificate rotation, which is precisely the combination that turns a weekend demo into a service you can actually depend on.