Vybe Eye Connector

Vybe Eye Connector is the WordPress side of the VybeFind Execution Layer. It

com) — the plugin is the

site-side agent for that service and does nothing on its own until paired. Once

paired with your VybeFind workspace, it pulls the changes your team has approved

in the Execution console and applies them in place:

• Title tags and meta descriptions — via Yoast, Rank Math, or All in One SEO

when present, or a native fallback when no SEO plugin is installed.

• JSON-LD structured data — injected into the page head, idempotently.

• Image alt text.

• Internal links — inserted into the target post content, de-duplicated.

• 301 redirects.

• New pages or posts, created from content you approved in VybeFind. New

content is created as a draft by default so you can review it before it goes

live; publishing immediately is opt-in per site from your VybeFind workspace.

If a page already exists at the target slug the plugin uses that page instead

of creating a second one, so a retry can never produce duplicate pages.

Every applied change is recorded locally with a hash of the value it wrote, so

the plugin can detect drift (something later changed the value out from

under it) and offer one-click rollback to the previous value.

How pairing works

• In VybeFind, open Execution and click Generate pairing code for your

site.

• In WordPress, go to Settings → Vybe Eye Connector, paste the one-time code,

and click Pair site. That is the only field to fill in — the plugin

com by default. (Agency or

) The

plugin generates a local keypair, exchanges the code for a per-site bearer

token, and stores it privately (never shown again).

• The plugin polls VybeFind every 15 minutes (WP-Cron). Each poll pulls pending

changes as an HMAC-signed envelope, verifies the signature, applies each

change, and reports the outcome back.

External services

com), the SaaS

service it is the WordPress client for. An active VybeFind account is required;

the plugin performs no external communication until you pair it with a workspace.

When and why it connects:

• At pairing (once, when you click “Pair site”). The plugin sends your

one-time pairing code, a locally generated public key, and your WordPress

version to https://<your-platform-host>/api/wp/pair in exchange for a

per-site bearer token. The platform host is the URL you paste at pairing

(VybeFind-hosted by default); all later requests are pinned to that host.

• Every 15 minutes (WP-Cron poll). The plugin requests pending approved

changes from /api/wp/changes using the bearer token. No site content is

uploaded on this request — it only pulls the change instructions your team

approved in VybeFind. 0 those instructions may include the full body

text of a new page or post to create (see below).

• After applying each change. The plugin reports the outcome

(applied / drifted / rolled_back / failed) and a hash of the value it wrote

to /api/wp/changes/<id>/status. When it creates a page it also reports the

resulting post ID, its permalink, its publication status (draft/published/…)

and whether a page already existed at that slug, so the platform can update

that same page later instead of creating a duplicate and can tell you honestly

whether the page is actually public. It does not transmit your existing page

content, visitor data, or personal data.

Data sent: pairing code, generated public key, WordPress version, connector

version, change IDs, per-change outcome hashes, and — for created or adopted

pages only — the post ID, its public permalink, its publication status, and

whether the page already existed. Data received: the change instructions

you approved in your VybeFind workspace (titles, meta descriptions, JSON-LD, alt

0 the title, slug and body content

of new pages to create).

Your use of the VybeFind service is governed by its terms and privacy policy:

• Terms of Service: https://vybefind.com/legal/terms

• Privacy Policy: https://vybefind.com/legal/privacy

Security

• The per-site bearer token and the signing keypair are stored as non-autoloaded

options and never printed back into the admin UI.

• Every changes envelope from the platform is HMAC-verified before anything is

applied — unsigned or tampered payloads are refused (fail-closed).

• All admin actions are capability- (manage_options) and nonce-guarded.

• Outbound requests only ever go to the platform URL saved at pairing.