Amazon Scraper API vs Proxy: Choose a Product Data Source
Distinguish authorized Amazon APIs, licensed product data and proxy-based page checks by record quality and access rights.
Read guideDICloak keeps proxy configuration at two related boundaries: the Proxies list stores an endpoint, while a browser profile decides which stored or custom endpoint it uses. Start with the credentials from your provider, configure one profile, and verify the observed route before opening a permitted account or data workflow.
This guide follows DICloak’s documented desktop flow. The labels can change between builds, so use the field names in your current screen as the final check.
Prepare the connection record
Keep the provider’s protocol, host, port, username, password, expected location, and any session instruction together. A provider URL is not automatically an API integration: DICloak’s own help center says it does not sell proxy access, so you supply the endpoint or extraction link.
Do not paste credentials into a profile name, screenshot, shared spreadsheet, or browser page. If the provider gives a SOCKS5 endpoint, keep it SOCKS5. For the difference between HTTP and SOCKS5 behavior, see HTTP vs SOCKS5 proxies.
Add the endpoint to DICloak
- Open DICloak and go to Proxies in the left navigation.
- Click Create Proxy and choose Custom Proxy.
- Fill the provider’s values in Proxy Type, Proxy Host, Proxy Port, Proxy Account, and Proxy Password. Use Remarks for a non-secret label such as the intended profile or region.
- Click Checking Proxy. DICloak documents this check as a way to report connection status and the observed IP, country or region, and time zone.
- Click Confirm, then return to the proxy list. A saved entry can be tested, edited, copied, or deleted.
The quick input option is useful when your provider gives a supported single-line format: enter it in Quick Input, click Parse, and inspect every populated field before saving. Parsing is only a field-mapping step; the check is the route test. DICloak’s FAQ covers the direct connection boundary. This guide does not treat the local API reference as proof of a separate browser API integration.
Related setup references: /blog/antidetect-browser-proxy-setup, /blog/http-vs-socks5-proxies, /blog/proxy-error-407, and /blog/proxy-ip-and-browser-diagnostics.
If you prefer to configure a profile directly, open Profile Management, click Create Profile, and find Proxy Settings. Select Custom Proxy, choose the documented Proxy Type, then fill IP Protocol, Host Port, Proxy Account, and Proxy Password. The profile screen also exposes IPQuery Channels and Checking proxy.
Attach the route to a profile
Create a fresh profile or edit the profile that will run the workflow. Under Proxy Settings, choose one of these modes:
| DICloak mode | Use it when | Check before launch |
|---|---|---|
| Custom Proxy | This profile needs one endpoint you are entering now | Protocol, host, port, and credentials match the provider record |
| Saved Proxies | The endpoint already exists in Proxies | The selected saved record is the intended one, not a similarly named entry |
| No Proxy | You intentionally want the device network | The profile will use the local network IP |
| API extraction | Your provider gives an extraction URL and the workflow supports that model | Proxy, Proxy Type, Extraction method, and Extraction Link are correct |
For Saved Proxies, select the stored endpoint and confirm the profile. DICloak also documents random selection of unused saved proxies. That can help with a pool, but it does not prove that a selected IP fits your target or account policy. Give each profile an explicit route when continuity matters; DICloak recommends avoiding the same proxy across multiple profiles.
For API extraction, use Test Extraction before Confirm. If duplicate avoidance matters to your team, enable Duplicate Check and use its Start action where available. This flow extracts an IP through the provider link; it is different from entering a fixed host and port.
Verify the live browser profile
Run the checks in the exact profile you will use:
- Save the profile and start it.
- Re-run DICloak’s proxy check if the profile screen offers it.
- Open a fresh tab and visit an IP check endpoint you trust or operate. Record the observed exit, timestamp, and target final URL without recording the password.
- Open one ordinary HTTPS page that is allowed for your workflow and check an expected title, selector, or record field.
A green proxy check proves that DICloak connected at that moment. It does not prove that a target will accept the address, that a login will succeed, or that a parser will find the expected content. For a phase-by-phase record, use the proxy IP and browser diagnostics guide.
Diagnose the failure phase
| Symptom | Check next |
|---|---|
| Field or format error | Match Proxy Type, protocol, host, port, and credential fields to the provider record. |
| Checking Proxy fails | Recheck host and port, credentials, expiry, and whether the endpoint is reachable from the DICloak runtime. |
| Profile opens on the local IP | Confirm the profile is not set to No Proxy and that the intended saved proxy is attached. |
| Proxy connects but the target returns 401, 403, 429, or a challenge | Classify it as a target response. Check account state, target terms, redirects, and request limits before changing the endpoint. |
| API extraction fails | Confirm the extraction link, method, proxy type, duplicate check state, and Test Extraction result. |
| The page loads but the expected field is missing | Inspect the final URL and page content. Route success and record validation are separate checks. |
Close the profile after the test so its session state is handled by your workflow. Keep only redacted evidence: profile name or id, phase, observed exit, target host, validator result, and timestamp.
Related setup references: antidetect browser proxy setup, /blog/http-vs-socks5-proxies, proxy error 407, and /blog/proxy-ip-and-browser-diagnostics.