Keep business-account capability explicit inside a unified API

A business label does not grant a universal surface

An Instagram account's professional or business context may affect eligibility, linked assets, permissions, and available resources, but DewEngine has not validated those combinations. No adapter is released. The project will not obtain broader behavior through scraping, limit evasion, or anti-detection techniques. A future product must declare the exact authorized account type and approved application purpose, then expose only methods proven for that identity instead of treating “business” as blanket entitlement.

Make product type and capability discoverable

A connected account should report its provider, provider product, stable public ID, native identity reference, health, granted capability set, and reasons for disabled methods. Business context that comes from linked assets should remain provider-scoped and observable. Customers need to distinguish missing permission, ineligible account, expired grant, policy block, and unimplemented method. Returning an empty collection for all of those states would make support and product logic unsafe.

Normalize lifecycle fields without erasing native meaning

Profiles, media, comments, conversations, and messages can share identifiers, timestamps, account ownership, and source metadata across a broader communication API. Their provider-specific fields, relationship rules, and update behavior still need extensions. The goal is to reuse tenant, pagination, command, and event infrastructure, not to claim that an Instagram post behaves like an email or that every business account exposes the same conversation history.

Authorize each read and write separately

A product may need profile context without publishing, inbox reads without outbound messages, or posting without comment management. Each capability should map to the minimum approved permission and a separate customer role. Runtime admission must check workspace authority, account health, provider scope, product policy, entitlement, and pacing. A successful connection cannot become standing consent for future methods added to a roadmap after the user completed authorization.

One API should still expose provider degradation

A unified surface can standardize correlation IDs, retries, webhook delivery, and account health, while Instagram-specific quota reasons and permission failures remain visible. Provider outage, application review changes, revoked linked assets, or account restriction should lower capability state without mislabeling stored customer data. Shared dashboards are valuable only when they help an operator locate the native failure and stop unsafe dispatch across the affected identity.

Prove the business vertical before attaching an offer

A complete release needs approved application configuration, eligible account fixtures, identity-safe authorization, method and event conformance, provider limit handling, tenant isolation, support inspection, export, retention, revocation, deletion, and production operations. Billing would then need a defined unit and reproducible entitlements. A design page, unified schema, or successful test account cannot establish a commercial Instagram business product or justify an invented fee.

• Publish account eligibility and missing-capability reasons beside every method
• Keep official and any separately reviewed experimental product IDs distinct