Connected Platforms & API Data Use Annex

1. Purpose and relationship with other documents

This Annex is the provider-specific public disclosure for DFF Reach. It describes connection methods, current capability boundaries, provider-derived data, purposes, retention and user controls without creating a separate contract for every provider.

If a provider's mandatory rules conflict with this Annex, the provider's rules control the provider-facing activity. Mandatory law also continues to apply. Nothing in this Annex makes an unavailable, unapproved or unverified provider capability available.

2. Core principles for every connected platform

DFF Reach uses official provider authentication, approved APIs or a first-party one-use link. It does not ask customers to provide a provider password or copied browser session as publishing authority.

• Connections are capability-specific. Identity connection, publishing, analytics, comments, replies, messages and deletion remain separate permissions or product states where the provider separates them.
• DFF Reach requests only the permissions needed for the feature the user deliberately enables.
• The customer must control or be authorised to manage the selected Page, profile, channel, organisation, board or Direct Food Finder account.
• DFF Reach can refuse, delay, quarantine or stop a provider action where authority is missing, expired, revoked, incompatible with provider rules or reasonably suspected to be compromised.
• Provider data is not treated as a general customer-data pool and must not cross between unrelated brands or customers.

3. Provider data DFF Reach may receive

The exact data depends on the provider, the permissions the customer grants and the separately released capability. DFF Reach should receive only the information needed for that capability.

• Provider account identifiers, display names, usernames, profile images and account type where supplied.
• A deliberately selected destination such as a Facebook Page, Instagram professional account, Threads profile, TikTok account, YouTube channel, LinkedIn identity or organisation, Pinterest board, Bluesky account or managed Direct Food Finder account.
• Granted permission scopes, authority state, expiry information, provider task or role information and provider review state where available.
• Draft content, captions, media metadata, schedules, destination choices, processing status and publication receipts.
• Post, media, comment, reply, conversation, message or analytics identifiers only when the corresponding capability is separately enabled.
• Webhook events, provider errors, deletion notices, deauthorisation events and revocation state needed to operate and secure the connection.

4. Purposes of provider-data processing

DFF Reach processes connected-platform information only for the released feature, the customer's instruction and associated security, support, provider-compliance or legal needs.

• Connect and verify authority over the selected destination.
• Show available destinations, permission state and capability status.
• Validate, schedule, transmit and reconcile publications the customer requests.
• Receive provider processing results, publication receipts and action-required errors.
• Display supported analytics with provider attribution when analytics is separately enabled.
• Receive and reply to comments or messages only after the relevant separate capability has been authorised and released.
• Secure the account, investigate incidents, prevent misuse and comply with provider or legal requirements.
• Disconnect authority, handle provider deauthorisation and carry out eligible deletion requests.

5. Customer authority and instructions

The customer instructs DFF Reach by choosing a destination, selecting content and options, confirming a publication or schedule, enabling an additional capability, or requesting disconnection or deletion.

The customer must comply with the destination provider's terms, content standards, advertising rules, intellectual-property rules and account restrictions, and must hold the authority required to act for any employer, agency client or other account owner represented through DFF Reach.

• Required commercial, affiliate, synthetic-media or regulated-product disclosures remain the customer's responsibility unless DFF Reach explicitly supplies a required provider control.
• DFF Reach must not be used for spam, fake engagement, scraping, credential collection, account farming, impersonation, trend manipulation, prohibited automation or circumvention of provider enforcement.
• Where messaging is released, the customer remains responsible for the lawful basis, sender identity, marketing classification and opt-out duties applicable to the message.

6. Provider and DFF Reach legal roles

A connected provider normally operates its own platform as an independent provider and determines its own purposes for account administration, platform security, content distribution, moderation and provider-side records. The provider's own terms and privacy notice also apply.

DFF Reach may act as an independent controller for Reach account security, billing administration, fraud prevention, provider-app compliance and legal obligations. Where DFF Reach processes provider-derived personal data solely on a business customer's documented instructions, DFF Reach may act as a processor, service provider or contractor under the applicable Data Processing Addendum.

The legal role can vary by activity and data item. A connected provider is not automatically a DFF Reach subprocessor merely because DFF Reach sends an authorised request to it.

7. Permission separation and capability status

DFF Reach keeps connection, publishing, analytics, comments, replies, direct messages, account discovery and deletion as separate capabilities. A visible connection is not proof that every capability is available.

The product can describe a capability as planned, private beta, under provider review, approved, live, expired, revoked, unsupported or disabled. Users may be required to complete a new provider grant when an additional capability needs additional authority.

• Publishing permission does not grant Inbox or direct-message access.
• Analytics permission does not grant publishing authority.
• Comment moderation and direct messages are distinct capabilities where the provider separates them.
• A provider permission is not requested merely because a future feature is shown on the roadmap.

8. Provider credentials and security

Provider client secrets, app secrets and reusable provider authority remain server-side. Reusable authority is encrypted where stored, bound to the correct brand and destination, and is not intentionally exposed in normal browser responses.

• OAuth state, callback addresses and returned identities are validated before a connection is persisted.
• DFF Reach records expiry and granted-permission state where the provider makes those values available.
• Authority may be revoked, quarantined or disabled after a suspected compromise, cross-brand exposure, provider incident or policy breach.
• Customers must not send passwords, access tokens, one-time codes or complete payment credentials to DFF Reach support.

9. Retention, disconnection, revocation and deletion

Provider data is retained only for the period reasonably needed for the enabled feature, security, support, billing, dispute, provider-review or legal purpose. DFF Reach does not apply one generic retention period to tokens, messages, publication receipts, analytics and security logs.

When a provider is disconnected, authority is revoked or a verified deletion request applies, DFF Reach may stop pending provider actions, invalidate reusable authority, unsubscribe supported webhooks, delete eligible cached provider data and retain only limited evidence where a lawful security, billing, publication, dispute or deletion purpose still applies.

Deleting information from DFF Reach does not necessarily delete content already published to a third-party provider. The customer may need to remove that content through the provider. Decentralised services may retain replicated copies outside DFF Reach's control.

10. Messages, comments and direct marketing

Messaging and comment features are not enabled merely because publishing is connected. DFF Reach will require the relevant additional provider authority and apply provider-specific conversation, reply-window, role, webhook and review requirements before those features are released.

DFF Reach must not be used for unsolicited bulk messaging or cold outreach that the provider or applicable law prohibits. Promotional social-media messages may be direct marketing under applicable electronic-communications rules, including the United Kingdom's PECR regime. Customers must honour valid opt-outs and suppression records.

11. Analytics and derived metrics

Provider analytics must remain labelled with their source. Where DFF Reach calculates a derived metric, the interface should identify it as a DFF Reach calculation and preserve the underlying provider provenance.

Retention and permitted reuse of analytics vary by provider and field. DFF Reach applies the applicable provider and legal restrictions rather than treating every metric as indefinitely reusable.

12. International transfers

Connected providers and infrastructure suppliers may process information outside the user's country. Where DFF Reach makes a restricted transfer and law requires a safeguard, DFF Reach will use an applicable recognised mechanism, which may include adequacy, recognised contractual clauses, a United Kingdom transfer addendum or another lawful safeguard.

This Annex does not claim that one transfer mechanism, processing region or legal role applies to every provider, country or processing activity.

13. Direct Food Finder

Connection method: a first-party, short-lived, one-use account-link authorisation for an account the user is authorised to manage. Release state: private beta.

Publishing and analytics are not yet treated as verified capabilities. The first-party connection may process selected account identity, account type, purpose-scoped authority, publication content, schedule, receipt and audit information when the relevant capability is released.

• DFF Reach does not require the user's Direct Food Finder password.
• Accounts must not be silently linked merely because email addresses match.
• Inbox access is unsupported through the current first-party connection.

14. Facebook Pages

Connection method: official Meta/Facebook Login for Business to a deliberately selected eligible Facebook Page. Release state: private beta.

The current Page publishing permission package configured by DFF Reach is pages_show_list, pages_read_engagement and pages_manage_posts. Publishing and analytics remain marked not verified until the release gates and provider approvals are complete.

• The current Page connection does not by itself authorise personal-profile posting, Groups, advertising or Inbox messaging.
• Facebook Inbox remains a separate, not-verified capability and requires its own provider permissions, review, signed webhooks, Page authority checks, reply-window controls, opt-outs, retention and deletion proof before release.

15. Instagram

Connection method: official Instagram Login for an eligible professional Business or Creator account. Release state: private beta.

The current publishing permission package configured by DFF Reach is instagram_business_basic and instagram_business_content_publish. Publishing and analytics remain marked not verified until the applicable release gates and provider approvals are complete.

• Messages, comments and insights are separate capabilities and are not implied by a publishing connection.
• Instagram Inbox remains not verified and must not be used as a general cold-outreach channel.

16. Threads

Connection method: official Threads authorisation using separate Threads authority. Release state: private beta.

The current publishing permission package configured by DFF Reach is threads_basic and threads_content_publish. Publishing and analytics remain marked not verified until the applicable release gates and provider approvals are complete.

• Replies and insights require their own supported provider scopes and controls.
• Private direct messages are unsupported unless an official third-party Threads DM capability is made available, approved and deliberately released.
• Signed uninstall and data-deletion callbacks can be used to revoke authority and delete eligible Threads-derived data.

17. TikTok

Connection method: official TikTok OAuth. Release state: private beta for the connection foundation.

The current connection requests the user.info.basic scope for basic identity. A future Direct Post capability requires separately approved video.publish authority. Direct Post remains not verified and unavailable for general use until the required Content Posting approval or audit, provider-specific user controls, media validation and real Production publication proof are complete.

• A future Direct Post flow requires the user to make provider-required choices such as the available privacy setting and applicable interaction or commercial-content controls.
• DFF Reach must not claim public publication success when an unaudited or restricted provider state only allows private visibility.
• Provider publication receipts and status must be reconciled before DFF Reach reports final success.

18. Planned providers: YouTube, LinkedIn, Pinterest, X and Bluesky

Release state: planned. These providers can appear in the controlled provider catalogue without being represented as live publishing integrations.

• YouTube: a dedicated Google OAuth grant and upload workflow must support provider-required title, description, privacy and audience choices before release.
• LinkedIn: an approved LinkedIn product and verified member or organisation authority are required; a generic OAuth token is not enough.
• Pinterest: public publishing remains unavailable until the applicable access tier, deliberate board selection, media validation and spam or duplicate controls are proven.
• X: any future integration must use official API authority and the current provider rules on user intent, duplication, spam, mentions, replies, messages and rate limits.
• Bluesky: any future integration requires supported authentication, secure revocation, anti-spam, rate, moderation and reporting controls, with truthful wording about decentralised replication and deletion.

19. User controls, provider changes and suspension

Depending on the released feature, DFF Reach provides or may provide controls to view capability status, reconnect, disconnect, revoke authority, delete eligible cached provider data, delete drafts, request an export and open provider-side account or deletion controls.

A user should not have to accept an unrelated optional permission merely to keep an existing supported connection working.

Providers can change APIs, permissions, review standards, pricing, data rules or feature availability. DFF Reach may restrict, suspend or discontinue one provider capability to remain secure, lawful and compliant without implying that unrelated providers must also be disabled.

20. Capability release rule and contact

DFF Reach should not describe a provider capability as live until the relevant provider documentation has been reviewed, required approval obtained, correct permission granted, a real authorised account tested, the end-to-end result proven, deletion and revocation tested, the corresponding legal disclosure published, and security and failure tests passed.

This Annex is a global baseline operated by DIRECT FOOD FINDER MARKETPLACE LTD in England and Wales. Mandatory rights under applicable local law are not removed. Provider-data questions can be sent to support@directfoodfinder.com with the subject “DFF Reach connected platforms”. Do not include passwords, access tokens, one-time codes or unnecessary private-message content.