Agoda Supply OAuth: Troubleshoot Source IP Error 60
For an Agoda Supply OAuth responseCode of 60, check the public source IP used by the failing process against the IPs registered in YCS > API access. Agoda identifies this response as an unauthorized source IP. Its Supply authentication guide documents IP registration alongside OAuth.
This page is for developers operating hotel channel manager integrations with Agoda Supply. Agoda describes YCS API as a way to manage rates, availability and inventory and retrieve property bookings.
Before you start
Use this guide for Agoda Supply channel-manager connectivity. Confirm the exact Agoda product and endpoint before applying it to another Agoda integration.
You need access to the deployed token and API clients, the responsible team’s YCS IP-registration workflow, and the egress configuration for each caller. If a channel manager operates the connection for you, involve that provider before changing your application’s networking.
Keep client secrets, access tokens, proxy passwords, and guest data in your approved secrets and data-handling systems. Do not paste them into tickets, screenshots, public logs, or AI prompts.
Start with the failing request
Use this sequence before changing credentials or networking:
- Record the destination host and path, HTTP status, response body error fields, UTC timestamp, and the service or worker that sent the request. Keep secrets and guest information out of the record.
- Check the public egress address used by that deployed process. A successful request from your laptop establishes only your laptop’s route.
- Compare the address with the registered IPs. If you already use QuotaGuard, compare it with the selected subscription’s dashboard IP pair and register both addresses.
- If the address is changing, select a stable egress route and apply it to every relevant HTTP client. Include separately deployed token workers, API workers and scheduled jobs.
- After correcting the route or registration, use the request allowed by your Agoda onboarding or support procedure to confirm recovery. Avoid replaying an inventory update or other write simply to check connectivity.
If the source IP matches and the request still fails, use the error fields to choose the next check. Repeated credential rotation can introduce another failure without correcting the route.
Check token traffic as well as API traffic
Agoda’s Supply OAuth example obtains a token with clientId and clientSecret at:
https://supply.agoda.com/token-based-authentication/exchange
The application then sends the token in an Authorization: Bearer header on connectivity API requests. These can be different network paths even when they belong to one integration. See the official request examples.
Make a small inventory of the actual callers:
| Caller | Route to inspect |
|---|---|
| Process that obtains or renews tokens | Its HTTP client and outbound network configuration |
| Worker that sends rates and availability | The client used for those API calls |
| Worker that retrieves bookings | Its independently configured client or SDK |
| Replacement instances and recovery jobs | Their deployment settings and outbound route |
For a proxy route, each caller must use a proxy-capable client configured for the intended proxy. Saving a proxy URL in an environment variable only helps clients that actually read it. An SDK may create its own connection independently of your diagnostic client.
The component that needs stable egress is the process opening the outbound connection to Agoda, or the gateway through which it connects. Your application’s inbound IP or website domain does not identify that route.
Separate IP rejection from authentication and throttling
Read the HTTP status and JSON responseCode separately. Agoda’s response-code field is not the same as an HTTP status or the separate code field.
- responseCode 60: Agoda identifies an unauthorized source IP. Compare the failing caller’s public egress IP with its YCS registration.
- responseCode 2: Agoda identifies invalid client credentials. Check the request format and the configured client ID and secret without exposing them.
- responseCode 41: Agoda identifies too many requests. Review token reuse and request volume, and follow Agoda’s rate-limit guidance or contact its support team. Changing IPs is not a remedy for a rate-limit block.
- HTTP 403: Agoda documents this for expired tokens. Check token expiry and the complete response before choosing a retry. An HTTP 403 alone does not establish an IP-registration problem.
Reuse valid tokens instead of generating one for every API call. See Agoda’s current authentication and error reference.
Preserve the error and timing information before retrying. A change in IP address does not repair invalid credentials, refresh an expired token, or establish that a request is safe to repeat.
Choose the stable egress route you can operate
| Route | When it fits |
|---|---|
| Existing fixed egress | You already operate a stable public source address or NAT path that covers every caller. Register that route rather than adding another network service. |
| Native cloud networking | You can manage the hosting platform’s networking and want egress controlled there. For example, Google documents Cloud Run static egress through a VPC and Cloud NAT configured with static addresses. |
| Existing channel manager | Your PMS already delegates the Agoda connection to another service. Establish which service makes the Agoda requests and owns IP registration before changing your PMS networking. |
| QuotaGuard | You control proxy-capable clients and want managed, stable outbound IPs while keeping the application on its current hosting platform. |
Before selecting addresses, confirm the source-address and proxy arrangement accepted for your Agoda partner setup, including any geographic or exclusivity requirements. Choose a region that meets those requirements and your latency needs. QuotaGuard egress follows the region selected for the subscription. Moving the subscription to another region changes its IP pair, so coordinate updated registrations before changing the route.
Use the subscription’s IP pair for a QuotaGuard route
Open the selected subscription’s Setup > Outbound connection information and copy its exact proxy URL and both static IPs. The connection details guide shows where to find them. Register the displayed IP pair, rather than addresses obtained by resolving the proxy hostname.
Configure the clients identified above using the relevant platform guide. QuotaGuard Static supports outbound HTTPS through CONNECT. Shield also encrypts the application-to-proxy hop with TLS. Both tunnel HTTPS payloads without decrypting them. See how HTTPS proxying works.
Standard shared addresses are shared with other QuotaGuard customers. If your approved architecture requires exclusive addresses, dedicated proxies are available on Enterprise and above through a support request. They provide address isolation; vendor quotas and approval requirements still apply. A change to dedicated infrastructure changes the connection details and IPs, so coordinate registration before switching traffic.
Verify the proxy route
From each configured client, a request to https://ip.quotaguard.com should report one of the subscription’s two IPs. A short series may show only one address; both still need registration. A new connection can use either IP. Registering only one can cause failures when the other is selected, without a predictable failure percentage. This checks the diagnostic client’s egress. Confirm the actual Agoda clients use that route and complete Agoda’s applicable access and certification process separately.
Confirm the actual Agoda route
A useful recovery check establishes all of the following:
- Each deployed token worker and API client uses the intended outbound route, including independently configured SDKs and scheduled jobs.
- The registered source addresses cover that route. For QuotaGuard, both subscription IPs are registered even if a short diagnostic test shows only one.
- The approved Agoda validation request succeeds from the actual integration. A successful IP lookup alone does not prove Agoda access, valid credentials, or certification.
If access still fails, retain a sanitized record of the endpoint, UTC timestamp, HTTP status, responseCode, caller, and observed source IP. Share routing questions with QuotaGuard support and Agoda-specific access or authentication questions with Agoda Connectivity support. Exclude credentials, authorization headers, and guest information.