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 guideMoreLogin can attach a self-owned proxy to a browser profile or a cloud phone profile. The fields are similar, but the runtime is different. Choose the profile type that matches the job, enter the endpoint exactly as supplied, run MoreLogin's detection in the UI, then test the permitted target in that same profile.
Choose the MoreLogin profile type
Use a browser profile when the work happens in MoreLogin's desktop browser. The documented path is Profiles > Browser, then select a profile and choose Edit Proxy. For a new profile, use New Profile > Browser Profile > Advanced Settings and open the proxy section.
Use a cloud phone profile when the work is meant to run in MoreLogin's cloud phone environment. MoreLogin documents a separate path: Profiles > Cloud Phone Profiles, select the cloud phone, and choose Edit Proxy. A new cloud phone starts at New Profile > Cloud Phone Profile. Do not treat a detection result from one runtime as evidence for the other.
Map the endpoint to the fields
MoreLogin's self-owned proxy guide lists HTTP, HTTPS, and SOCKS 5 proxy types. Fill in the proxy host, port, account, and password from the endpoint record. Keep the password in MoreLogin's credential field; do not paste it into a profile name, note, screenshot, or shared run log.
| Input from the endpoint | MoreLogin field | Check before saving |
|---|---|---|
| Protocol | Proxy Type | It is the protocol your endpoint actually exposes: HTTP, HTTPS, or socks5 |
| Host or IP | Proxy host | Use the host exactly as supplied |
| Port | Port | Keep it numeric and paired with that host |
| Username | Account | Leave empty only when the endpoint uses another documented auth method |
| Password | Password | Keep it private and do not reuse a browser account password |
| Mobile proxy control URL | Refresh URL | Use only when the provider documents it for a mobile dynamic proxy |
The guide also lets you choose an IP Query Channel: IP2location, MaxMind, DB-IP, or IP-API. MoreLogin says these channels can show slightly different results. If the displayed location does not match the endpoint record, change the query channel and record which one you used. That is a display and lookup choice, not a promise that a target will return the same location.
Detect the route, then validate the work
Save the proxy and run MoreLogin's proxy detection before starting the profile. When a browser profile starts, MoreLogin's detection page shows the current IP address, operating system, geographic location, and other browser information. Keep the result as route evidence with the profile name, timestamp, query channel, and redacted endpoint identifier.
The detection page does not establish that an approved target will return the record you need. Open the permitted target in the same profile and check a concrete result such as the final URL, response status, page title, or required field. If you are testing an endpoint before adding it to MoreLogin, the curl proxy guide shows a separate transport check. It does not replace the in-profile check.
For a repeatable country-sensitive check, hold the target, account state, language, and profile constant. An IP lookup is one signal; the target can apply its own locale, account, or access rules. Keep those outcomes separate in the run record.
Use Refresh URL only for the right proxy
MoreLogin documents Refresh URL for mobile dynamic proxies. Calling or refreshing that URL can change the IP. When several profiles use the same mobile proxy, MoreLogin says the change can affect all of those profiles. Treat the refresh as a shared state change: finish or pause related work first, then run detection again in every affected profile.
Do not add a made-up refresh URL to a residential or datacenter endpoint. If the provider did not give you a mobile refresh URL, leave the field empty. If you need to reason about a route that should stay the same through a login and pagination sequence, read the HTTP versus SOCKS5 comparison and use the provider's documented session behavior.
Diagnose the failing phase
| What you observe | Inspect first | Next action |
|---|---|---|
| The field is rejected | Proxy type, host, and port | Match the protocol and fields to the endpoint record |
| Detection fails | Reachability, credentials, and the selected query channel | Recheck the endpoint outside the profile, then retry the profile check |
| Detection passes but the target fails | Final URL, target status, account state, and target policy | Classify this as a target or session problem; a green route check is not target access |
| The displayed location is unexpected | IP Query Channel and provider route | Compare another documented query channel and retain the chosen channel in evidence |
| Several profiles change route together | Shared mobile proxy and Refresh URL | Stop the related run, refresh deliberately, and recheck each profile |
| An existing profile cannot be edited safely | Profile state | Stop the profile before changing its proxy and reopen it for a fresh check |
MoreLogin's API reference exposes proxyId on profile create and update and documents POST /api/env/start for starting a profile. The local interface requires the MoreLogin client to be started and logged in. Use that API boundary only when your automation is already authorized for the account; a profile API call still needs the same in-profile route and target checks.
For the wider browser-profile workflow, see the antidetect browser proxy setup guide. If authentication fails with a 407, use the proxy error 407 guide to separate credentials from target behavior.
Close the browser or cloud phone profile after the test using the product's stop control. Retain only redacted evidence: profile identifier, protocol, phase, observed result, query channel, target host, and timestamp. Use MoreLogin with accounts and targets you own or are authorized to operate, and respect their terms and request limits.