Developer documentation

What is implemented

This release includes the brand website, complete policy pages, an in-memory scheduler and TikTok composer, local demo channel disconnection, and a real private-inbox contact endpoint. The scheduler never contacts a social network. There is no OAuth authorization endpoint, action API, MCP server, issued API key, published SDK, payment collection, production vault, or analytics integration in this repository.

The 34-platform language describes the product vision, not an inventory of enabled integrations. The five-channel interactive preview shows how the publishing experience should work. The homepage MCP, TypeScript, and cURL snippets illustrate a proposed interface; their action URLs are not active APIs. A website and a policy are necessary review materials, not sufficient proof of an approved developer application.

A publish is an explicit decision

Select an original video or inspect the supplied 9:16 sample. Local files stay in the browser. The preview accepts MP4/WebM up to 100 MB and 180 seconds; production limits must come from the target platform.
Edit the caption and hashtags. Show the creator identity and a playback preview before asking for consent.
Choose an audience yourself; never inherit a public default. The demo shows the three requested TikTok enum values, but a live application must restrict the list to the current creator-info response.
Choose interaction permissions and commercial disclosures. Nothing is preselected. Paid partnerships cannot be private; a conflict requires the user’s own correction.
Confirm music rights and applicable branded-content terms, pick a future date and local time, inspect the review, and explicitly schedule the demo record.

The preview records the item in the displayed week and releases the video preview. It does not upload or publish. A connected implementation must revalidate permission and creator limits before a scheduled job begins. TikTok does not become a native scheduling API simply because the application has a calendar; scheduling belongs to the application’s worker.

In production, media must use temporary HTTPS transit, be automatically purged within 30 days of ingestion, and be sent only after explicit consent. An API acceptance response is not a successful publication: poll the documented status endpoint or verify signed platform webhooks, then show processing, published, failed, or cancelled state accurately. Platform processing may take several minutes.

TikTok Direct Post

video.publish authorizes creator-approved Direct Post operations. user.info.basic is used only when needed to identify the consenting creator. video.upload is a separate upload-to-inbox capability, not a substitute for Direct Post permission; it should not be requested for a Direct Post-only flow.

The live composer must retrieve the latest creator information, display the creator’s nickname, honor privacy_level_options and max_video_post_duration_sec, and disable interactions the creator has disabled. Privacy and comment/duet/stitch controls have no affirmative defaults. If the creator cannot post, stop rather than queueing around the restriction.

Commercial disclosure starts off. Turning it on requires “Your brand,” “Branded content,” or both. Your brand is labeled promotional content; any third-party branded content is labeled paid partnership. Only-you visibility is incompatible with branded content. The user must consent to TikTok’s Music Usage Confirmation and, for branded content, the Branded Content Policy.

Unaudited API clients are restricted to SELF_ONLY, have a small test-user cap, and must satisfy TikTok’s current requirements before public sharing. This preview is not an approved Content Sharing partner. TikTok requires a product for authentic creators and a broad audience; an internal-only account-upload utility is not an acceptable Direct Post use case. Do not submit the demo as if it were a working authenticated service.

For server-held original media, PULL_FROM_URL must use a domain or prefix whose ownership is verified. For media on a creator’s device, follow the documented FILE_UPLOAD flow. Preserve original content and never add promotional watermarks. See TikTok’s Content Sharing Guidelines.

Meta: Facebook, Instagram, and Threads

Permission	User-facing purpose
`pages_show_list`	Let the user select a Page they can manage.
`pages_read_engagement`	Read permitted Page metadata needed by the selected workflow.
`pages_manage_posts`	Create and manage only Page posts the authorized user directs.
`instagram_basic`	Identify the connected professional Instagram account in the Facebook Login flow.
`instagram_content_publish`	Publish user-approved media to that professional account.
`threads_basic`	Identify the consenting Threads account.
`threads_content_publish`	Publish the user’s explicitly approved Threads content.

These scopes do not authorize unrelated profiling, collection of friends’ data, or posting to arbitrary accounts. Instagram Login uses its own instagram_business_* permission family; choose the actual login product and document its permissions instead of mixing scope names across products. Request only what the enabled user-facing feature needs.

Meta app review, business verification where required, and advanced access must be completed separately. Graph API v25.0 is the stated integration review target, not an approval badge. Configure the Data Deletion Instructions URL as https://pulseflow.arieltolome.com/data-deletion. This instructions page is not a signed-request deletion callback; do not configure it as one. Review Meta permissions, Instagram Platform, and Threads API before implementation.

Google and YouTube

https://www.googleapis.com/auth/youtube.upload is the intended scope for creator-directed video uploads. Read scopes such as youtube.readonly, or yt-analytics.readonly for a separate analytics feature, must be requested incrementally only when that feature is implemented and visibly needed. An upload permission is not consent to unrelated Google data processing.

The privacy policy contains the mandatory Limited Use commitment. Google API data must not be sold, used for personalized advertising, used for credit decisions, or passed into general-purpose model training. OAuth verification and the YouTube API compliance audit are distinct processes; approval of one does not establish the other. Uploads from unverified projects may be restricted to private visibility.

Provide a working disconnect path and direct users to Google connected apps for independent revocation. Review the Google API Services User Data Policy and YouTube developer policies.

LinkedIn OAuth 2.0

w_member_social permits posting on behalf of the authenticated member. Optional openid, profile, and email belong to an explicit OpenID Connect sign-in feature, not an automatic request for every publisher. Organization posting requires the relevant approved product, w_organization_social, and verification that the member can act for the selected organization. Additional organization-read or administration permissions must be justified by an actual feature.

Use the authorization-code flow, validate a single-use state value and exact redirect URI, and exchange the code only on the server. A visible profile or company logo does not establish permission to post. Document/carousel publishing must use the supported current media and Posts APIs, subject to the account and product’s access. See Share on LinkedIn and LinkedIn authentication.

X: OAuth 2.0 and OAuth 1.0a

For OAuth 2.0 Authorization Code with PKCE, the posting workflow uses tweet.read, users.read, and tweet.write. Request media.write only for media upload and offline.access only when the user chooses persistent scheduling that needs refresh tokens. Do not request direct-message, follow, or like permissions for a publishing-only product.

OAuth 1.0a does not use the OAuth 2.0 scope strings. It uses app-level permission settings such as Read and write, with a server-side consumer secret, user access token/secret, and signed requests. “Read, write, and Direct Messages” is unnecessary for this workflow. The demo’s “OAuth 1.0a verified” label is explicitly simulated metadata, not a claim about an actual connected account.

Threads must preserve part ordering, report partial failure, and never silently duplicate earlier parts. API access tiers and quotas still apply; neither OAuth method bypasses them. Read X’s OAuth 2.0 scope reference and OAuth 1.0a user tokens.

TikTok root verification hook

Obtain the actual verification filename and contents from the TikTok Developer Portal. Never invent a verification token. Next.js serves files placed in public/ at the root: a portal file named tiktok…html belongs directly there, unchanged, before building and deploying.

Alternatively, the included root handler accepts TIKTOK_VERIFICATION_FILE and TIKTOK_VERIFICATION_CONTENT as server environment variables. Filenames must begin with tiktok, contain only letters, digits, underscores, or hyphens after that prefix, and end in .html or .txt. Only the exact configured filename returns the exact configured content; everything else is a real 404. Empty configuration returns no verification document.

Use one method, not both for the same path. Restart the server after changing runtime verification values. Check the exact root URL over public HTTPS for HTTP 200 and byte-for-byte contents, then request verification in TikTok. The hook is implemented; domain ownership is not verified by this website build. DNS and TLS must point to the deployed application first.

One origin for every public reference

SITE_URL is the single canonical-origin setting. Its default is https://pulseflow.arieltolome.com/. Set it to an absolute HTTP(S) origin without credentials, a path, query, or fragment. Canonicals, OpenGraph URLs, robots, sitemap, and these review URLs are derived from it; internal navigation is origin-relative and moves with the site. Rebuild and restart after changing the origin.

App homepage: https://pulseflow.arieltolome.com/
Privacy URL: https://pulseflow.arieltolome.com/privacy
Terms URL: https://pulseflow.arieltolome.com/terms
Data Deletion Instructions URL: https://pulseflow.arieltolome.com/data-deletion

For a future authenticated implementation, register one exact callback per provider, such as https://pulseflow.arieltolome.com/api/oauth/tiktok/callback, https://pulseflow.arieltolome.com/api/oauth/meta/callback, https://pulseflow.arieltolome.com/api/oauth/google/callback, https://pulseflow.arieltolome.com/api/oauth/linkedin/callback, and https://pulseflow.arieltolome.com/api/oauth/x/callback. These are callback naming conventions, not working routes in this preview. Do not register them for production until the corresponding authorization code exchange, PKCE/state checks, consent records, and token custody have been implemented and tested. Changing a domain also requires updating each platform’s allowlist; an environment update cannot modify external dashboards.

Run and operate this website

Use Node.js 22.22 or newer, with a current supported Node LTS recommended. Dependencies are pinned by package-lock.json. The production build includes strict TypeScript checks and ESLint; no browser font download is required because fonts are bundled locally.

npm install
npm run build
# Local production preview (sets the contact request origin):
SITE_URL=http://localhost:3000 npm run start
# Open http://localhost:3000

# Against an already-running preview:
VERIFY_ORIGIN=http://localhost:3000 npm run verify

For public hosting, set SITE_URL to the deployed HTTPS origin before building and starting. Supply a private, persistent CONTACT_INBOX_DIR outside the web root. The default .data/contact is suitable for a persistent single-host process, not an ephemeral serverless filesystem. Mount durable storage, restrict parent-directory access, and run one writer instance unless shared admission controls are configured. This site has a real contact POST route and is not a static-export-only application.

Contact requests: record first, acknowledge second

POST /api/contact requires a matching Origin and Content-Type: application/json. Its body has name, email, optional company, topic (Access, Support, Privacy, or Security), message, consent: true, and the empty honeypot website: "". It accepts messages of 20–5,000 characters and at most 16 KiB total. Only a durable private-file write receives HTTP 201 with a requestId. Invalid input, origin mismatch, quota, and write failures are non-success responses.

No email service is configured or implicitly used. The operator must monitor the private inbox and reply using the supplied address. Do not expose the inbox over HTTP, commit it, or place it under public/. Set the same CONTACT_INBOX_DIR for the server and the local operator command:

node tools/inbox.mjs list
# Read a specific request; the command marks it read:
node tools/inbox.mjs show REQUEST_UUID
# Permanently delete a resolved request after review:
node tools/inbox.mjs delete REQUEST_UUID

The UUID comes from the list output or successful form receipt; it is not an authentication token. CLI output contains personal information and belongs only in a private operator terminal. Delete inquiries within 90 days after resolution unless a documented legal retention exception applies. The process-local 30-request/hour limit resets on restart; public hosting needs edge-level abuse protection. Set the host’s storage, backups, logs, and certificate policies consistently with the privacy notice.

Before public launch, review the supplied corporate name and policies with the operator, verify the support/privacy mailboxes, provision the hostname and HTTPS, configure durable inbox storage and monitoring, and test domain verification with the real portal file. Before social-platform app review, implement and verify the actual connected service; never describe this UI demonstration as that backend.