Permissions and access

Homa requests only the permissions required by the features a customer actually enables. A permission that is not needed is not requested, and a permission that is no longer used is removed at the next reauthorization.

• Scopes are grouped by capability, so a customer using only Instagram messaging is not asked for Page content permissions.
• Read and write capabilities are requested separately wherever the platform allows it.
• Requesting fewer permissions shortens App Review and reduces the consequences of a token compromise.
• Each requested scope is documented internally with the feature that justifies it.

1. Requested. Homa asks for a scope during the authorization redirect.
2. Granted. The user approves it on Meta’s consent screen and selects which assets it applies to.
3. Active. The token carries the scope and the associated feature works.
4. Degraded. The user removes an asset or declines a scope on reauthorization; the dependent feature stops.
5. Revoked or expired. The scope is no longer usable and the token must be replaced or removed.

A granted permission is not permanent. Users can change asset selection at any time from their Meta account settings, and Homa must handle a previously working capability disappearing without notice.

Meta distinguishes between access to assets your own app team administers and access to assets belonging to other businesses. This distinction determines whether a feature can serve customers at all.

App Review is Meta’s evaluation of whether a requested permission matches a legitimate, clearly demonstrated use case. It is a precondition for advanced access, not a formality.

• Each permission is reviewed against a specific described use case.
• Reviewers expect a working demonstration of the feature that consumes the permission.
• A published privacy policy, terms of service and user data deletion instructions must be reachable at stable public URLs.
• Requesting a permission without a demonstrable use case is a common rejection reason.
• Approval can be withdrawn later if the app’s behaviour changes materially.

This site hosts the required public documents. The privacy policy, terms of service and data deletion instructions are linked from every page footer so they remain discoverable to both users and reviewers.

Some permissions and products additionally require the business behind the app to be verified with Meta. Verification concerns the legal entity, not the application code.

• Verification is performed by the business that owns the Meta app.
• It typically requires documentary evidence of the legal entity.
• It is separate from App Review; a feature may need both.
• Neither verification nor review implies any partnership with or endorsement by Meta.

Users may withdraw a permission at any time, from Homa or from Meta. Both routes must lead to the same outcome.

From Homa CRM

Disconnecting the integration deletes the stored token, deactivates the connection and records the action in the audit log.

From Meta account settings

Removing the app triggers the deauthorize callback. Homa treats this exactly like an in-product disconnect.

Partial revocation

Deselecting a single asset leaves the connection active but narrows its reach. Dependent features stop for that asset only.

A connection needs to be re-established when a token expires, a permission set changes, or a user’s administrative access to an asset is removed.

1. Homa detects the failure and marks the connection as needing attention.
2. The customer is prompted inside Homa CRM rather than through an unsolicited email link.
3. The user repeats the authorization flow from /connect.
4. Newly granted scopes replace the previous set; removed scopes stop working immediately.