Incogniton Proxy Integration

Incogniton is a multi-profile browser for Windows 10/11 (64-bit) and macOS (Apple Silicon and Intel) that isolates cookies, storage, and fingerprint surfaces between browser profiles. Each profile behaves like a separate machine, which teams use for authorized client workspaces, QA environments, and account security. The free plan includes 10 browser profiles; REST-API and Selenium automation, the Synchronizer, and team management are gated to paid tiers. Do not use fingerprint controls to impersonate people, create fake accounts, or bypass platform enforcement - profile isolation is an operations tool, not an identity fabricator.

The pairing works because both sides keep one contract. Databay exposes a single gateway - gw.databay.co:8888 - where pool, country, and session live in the proxy username, and Incogniton exposes a Proxy Library that is, in its docs' words, "a central place to manage, assign, and reuse proxies across profiles without re-entering credentials each time." Save one Databay entry per workspace in the library, and every profile that needs that exit selects it without anyone retyping credentials. Cookies, fingerprint, and exit IP then travel together as one unit per profile, which is the property that makes separated workspaces actually separate.

You need a Databay account with the gateway host, port, and username:password pair from the dashboard, and Incogniton installed (free plan is enough for manual setup; automation needs a paid tier). Plan the proxy username per workspace before touching the UI: USER-zone-residential-countryCode-us-sessionId-client01 style flags decide pool, geography, and stickiness per profile. Keep credentials in a password manager - never embed production secrets in screenshots or shared templates.

Incogniton's documented flow: open Proxy Library from the left-side menu and click + New proxy (top right).

1. Pick the connection type - the Add proxy form offers HTTPS or SOCKS5. Either reaches the same Databay gateway.
2. Fill Proxy (ip:port) with gw.databay.co:8888, then Proxy username and Proxy password. Shortcut: pasting gw.databay.co:8888:USERNAME:PASSWORD straight into the ip:port field auto-populates the remaining fields.
3. Optionally set a Display name, a Group, and Notes - name entries after the workspace whose sessionId flag they carry, so the library maps one-to-one onto your workflows.
4. Leave the Rotating proxy toggle off: Databay rotation is controlled by the username (no sessionId = fresh IP per connection), so the rotation-URL field has no job here.
5. Click Check to verify the connection, then Add - or Add to list to stage several entries first.

Each profile's Proxy tab offers four documented options: Proxy Library, Buy proxy, Custom proxy, and Free proxy. For Databay:

1. Choose Proxy Library, then Select from Proxy Library, and pick the saved workspace entry - no credentials re-entered.
2. Or choose Custom proxy and enter the connection type and gateway details directly, then click Check "to verify connectivity" before saving. Use custom entries for one-off exceptions; the library is the pattern for anything reused.
3. Leave the profile toggles Fill language based on IP, timezone, and location on their IP-based defaults so the profile's locale story matches the Databay exit country automatically.

Geography and persistence are Databay username flags, so the same library mechanics cover every case. Add -countryCode-us (or any published country code) when an authorized test needs a US network origin. Add -sessionId-client01 when the workflow needs IP continuity - the gateway pins the exit for up to 120 minutes, subject to live availability, and it is not a dedicated device: do not expect the same IP back after an idle period. One profile, one sessionId label is the rule that keeps workspaces from ever sharing an exit identity. Pool choice is a flag too: zone-residential for reputation-sensitive targets, datacenter for throughput - compare on the residential and datacenter pages.

Verify at three layers before trusting a profile. First, the Check button in the Add proxy form or profile editor must pass. Second, read Incogniton's documented status icons in the profiles list: a red cancel icon means the profile failed to launch on a proxy connection error, while a red lightning bolt with the green check means the proxy is slow but working - a latency signal, not a failure. Third, inside the launched profile, open the Databay IP checker and confirm the exit IP and country match the username's countryCode flag. If your direct address appears instead, stop before signing in to anything and fix the assignment. For debugging outside Incogniton, its docs recommend testing the same credentials in Firefox with FoxyProxy - if the proxy works there but not in Incogniton, the mismatch is in the profile configuration, not the gateway.

Incogniton's troubleshooting doc frames failures as "a mismatch between what your proxy expects and what's configured in Incogniton", and the same four mismatches cover Databay setups:

• Protocol mismatch - a SOCKS5 entry created under the HTTPS connection type (or vice versa) fails the check. Recreate the entry with the type that matches the credentials you tested.
• Missing port - the ip:port field needs gw.databay.co:8888, not the bare host.
• Wrong auth mode - Databay gateway entries use username:password; if the account is configured for IP-allowlist auth instead, the credential fields must be empty and the machine's IP must be on the allowlist.
• Environment leaks - if the exit is right but the page behaves oddly, Incogniton suggests manually setting timezone, WebRTC, and geolocation by disabling the three Fill-based-on-IP toggles; with a correctly matched Databay country flag the defaults are usually the safer choice.

On paid tiers, the Incogniton desktop app exposes a local REST API at http://localhost:35000 (the app must be running and the profile status Ready). Profile operations cover POST /profile/add, GET /profile/all, /profile/launch/{profile_id}, /profile/status/{profile_id}, and /profile/stop/{profile_id}, so fleets can be provisioned and driven programmatically while each profile keeps its assigned Databay exit. For browser automation, POST /automation/launch/puppeteer with {"profileID": "..."} returns a puppeteerUrl you connect to with puppeteer-core (puppeteer.connect({ browserURL, acceptInsecureCerts: true })), and GET /automation/launch/python/{profile_id} starts a Selenium-compatible session - the docs allow around 30 seconds for browser initialization. The runtime patterns are the same as our Puppeteer and Selenium runbooks; the difference is that Incogniton owns the browser and the proxy stays attached to the profile.

Residential and datacenter pools provide different network origins, availability, latency, and price. Choose from the authorized test requirement and measure the result: residential for reputation-sensitive targets where the exit must look like a household connection, datacenter where throughput and cost dominate. Do not switch pools or session IDs to route around a 403, 429, CAPTCHA, or other source control; stop, back off, or use an approved API or access method instead.

Maintain written account authorization, role-based access, multifactor authentication, profile ownership, access logs, and offboarding. Incogniton's team features (roles with granular permission categories, including dedicated Proxy Library permissions on paid tiers) map cleanly onto that discipline - use them to keep who-can-touch-which-exit explicit. Give profiles separate storage for security, not as invented identities. Apply source terms and one domain-level request budget across all profiles. Databay's Acceptable Use Policy prohibits spam, deceptive engagement, and unauthorized access.