Miro Integration Reference Architecture

Overview

Put each capability at the correct browser, backend, tenant, and persistence boundary; use the evidence produced here to make the next decision explicit and reviewable.

Prerequisites

• Approved Miro application, tenant, and board scope
• Current repository and deployment evidence
• Named owner, success criteria, and rollback or recovery boundary

Tool Discipline

Use Read, Glob, and Grep to inspect the repository, configuration names, adapters, tests, and evidence. Use WebFetch only for current official Miro documentation. Use Write or Edit after confirming the requested mode, target environment, tenant, board, and approval boundary. These declared tools do not call authenticated Miro APIs or deployment CLIs; implement client, configuration, and test changes, then return exact operator commands or an approval-gated handoff for live execution.

Current Contract

• Web SDK operates in loaded board contexts; REST requires OAuth Authorization Code.
• Hybrid apps configure SDK authorization for backend REST authentication.
• Tokens must bind to app, user, team, and scopes.
• Durable change capture requires reconciliation because REST webhooks were retired.

Authentication

For REST work, use OAuth 2.0 Authorization Code with the narrowest Miro scopes. Bind each encrypted token record to its user, application, authorized team, and granted scopes. Never print access tokens, refresh tokens, client secrets, authorization codes, or board content.

Instructions

1. Map actors, tenants, boards, data classes, journeys, and destructive operations.
2. Assign in-board interaction to Web SDK and durable orchestration to backend REST.
3. Define OAuth callback, rotating encrypted token storage, tenant authorization, and revocation.
4. Add weighted queues, cursor checkpoints, operation records, reconciliation, and safe telemetry.
5. Design failures for auth loss, tenant mismatch, 429, ambiguous writes, drift, and outage.
6. Review scopes, retention, capacity, recovery, and experimental use with owners.

Approval Boundaries

Shared tokens, browser-held client secrets, unbounded polling, and experimental dependencies require architecture/security approval and should normally be rejected. Pause when the responsible owner or exact target is uncertain.

Output

Return scope, observed contract, proposed or completed actions, verification evidence, approvals, residual risks, and next owner. State what was not inspected or changed so the receipt cannot overclaim coverage.

Error Handling

Examples

The example is a redacted operator receipt; identifiers are hashes or bounded labels, not board content or credentials.

ui=web-sdk; auth=backend-oauth; rest=v2; tokens=tenant-bound; events=5m-reconcile

Resources

• Skill-specific official documentation
• REST auth from Web SDK
• REST introduction