Changing Rates in Agoda's Partner Portal

Agoda holds several prices for the same night. The one a guest sees is assembled at search time, which is why a saved change can look like it did nothing.

Last updated: October 25, 2026

You save a new figure in the Agoda partner portal, refresh, and the old price is still there. So you change it again. That second edit is where most rate errors start. One night on Agoda carries more than one price, and the one a guest sees isn't the one you typed. It's assembled later, at search time, from the layers underneath.

Key Takeaways

• One night, several prices. The figure you set, any campaign attached to it, and the price a guest is shown are three different things.
• Find the layer before the pen. If a campaign is live, changing the base rate can be correct and invisible at the same time.
• The display assembles late. A saved change and a visible change are separate events, and the gap isn't a fixed number.
• Re-editing is the real cost. A second edit made while the first is still settling is how two layers end up disagreeing.
• Verify like a guest, in their conditions. Clean window, their country, their currency, their occupancy.

The prices that sit behind one night

The rate you set is the floor of the stack, not the whole of it. Above it sit the things you've attached over time: a room-only version and a version with breakfast, a campaign for a slow stretch, a rate that only applies to a particular market or a particular length of stay. Each is legitimate. Each is a separate object with its own dates.

Then there's the price itself, which is a calculation rather than a record. It takes the rate that applies to those dates, applies whatever is attached, converts to the currency the searcher is using, and adds the tax treatment that applies to that market. That's the number in the search result.

Which means the answer to "what's my Agoda price for the fourteenth" is incomplete until you say for whom. A guest searching from one country in one currency, for two adults, on a flexible rate, isn't looking at the same number as a guest searching for four.

The stack also grows without a decision. A campaign opened for one quiet week stays open because nobody closed it. A plan created for a corporate account keeps selling after the account moves on. None of it looks like a mistake on any single screen, which is why the layer count is worth checking once a season rather than once a problem.

Hold onto one consequence of that: a price you can't explain is usually a layer you've forgotten, not arithmetic that's gone wrong. The figure sits under something you set months ago and never took down. Read the stack before you doubt the number.

Which field you're actually editing

Most of the confusion is a layer question. You open the rate screen, change a figure, save. But the dates you care about may not be selling off that figure at all. Something is attached on top of it, and the attached thing wins.

So read first. Before you change anything, answer two questions about the dates in front of you. Is a campaign or a derived rate covering these nights right now? And is the figure on screen what those dates actually resolve to, or just the base they'd fall back to?

If something is attached, you have a choice, and it isn't a technical one. Change the layer that's actually selling, which is the fast fix. Or change the base, accept that no guest will see it until the layer above comes off, and note that you did it. Both are legitimate. Do the first while believing you did the second, and you'll spend three days wondering why nothing moved.

There's a third case worth naming: the dates you edit aren't the dates you think. A rate applied from a start date, a campaign with its own window, a plan that only covers part of the month. Check the range on the object you're editing, not on the calendar behind it.

Why the display lags

The guest's price is built when someone searches. Nothing you save can appear before the next search that includes your dates, and the search that shows it may be a different one from the page you're refreshing. Your own browser makes this worse, because it holds the version it fetched a minute ago.

That's the mechanical half. The other half is that the thing you're looking at may not be the same view. A partner view and a guest view differ in country, currency, occupancy and rate conditions, and each of those can change the number without anything being wrong.

There's a social version of the same lag. Two people editing one property, one in the portal and one in a connected tool, will each see their own version settle first and conclude the other one broke it. The fix isn't technical: agree who edits rates for which dates, and say so in the note you keep.

This is where a saved change and a broken change look identical. You can't tell them apart by refreshing harder. You tell them apart by comparing two views that should agree, at the same moment.

localsbnb.com is where that comparison happens for connected channels. The Agoda connection sits beside Airbnb, Booking.com and Trip.com, so the calendar shows each channel's rate and status next to the dates. Same read on both sides? The change saved. A different one? That's a real error, not a slow screen.

A verification routine that holds

The routine is short. The order is the point. Run it the same way each time and the ambiguous cases stop being ambiguous.

1. Open a private window. No session, no cached page, no remembered currency.
2. Set the guest's conditions: country, currency, occupancy, and the rate condition you actually sell. Three of these four are usually wrong by default.
3. Search the exact dates, not the month. A calendar shows aggregates; a search shows one number.
4. Compare what you see with the channel side of the calendar, where the rate that was sent is visible next to the dates.
5. Write down the time you checked and what you saw. If it's a lag, the next check settles it. If it's an error, the note is what you send to whoever fixes it.

Two habits keep this honest. Never re-edit inside the same session you made the first change in; you'll be editing against a screen that hasn't caught up. And never verify at an occupancy or a currency you don't sell at, because a correct number under the wrong conditions reads exactly like a wrong one.

When the two views disagree, keep the evidence rather than the opinion. The date, the occupancy, the currency, the number you saw, and the time you saw it. That's enough for anyone supporting the account to run the same check. It's also the difference between a ticket that closes and one that bounces for a week.

FAQ

Why is the old price still showing after I saved?

Because the guest's price is assembled at search time from the layers under it, and what you refreshed may be a cached page. Check in a private window at the guest's country, currency and occupancy before concluding the save failed.

Should I change the base rate or the campaign?

Whichever is currently covering those dates. A campaign on top of the base wins, so a base change under a live campaign is correct and invisible. Decide which layer is selling first, then edit that one.

How long should I wait before deciding something's wrong?

There's no fixed number, and waiting isn't the test. The test is whether the channel side of your calendar agrees with the portal. If the two views disagree, re-checking the same screen won't resolve it.

A rate change is a small event with a long tail. Most of that tail gets spent looking at the wrong view. If you'd rather compare the channel's rate against the dates in one place, localsbnb.com keeps that view open while you work.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. How a partner portal assembles a displayed price, which layers apply and when a change becomes visible all differ by platform and change without notice. Confirm the current terms of each platform you use before you edit a live rate.