Revise and renegotiate deals

As the selling party, you might need to revise a deal at different stages of its life cycle: while initiating a deal with the buying party, you might revise changes to the proposal or live stage. On the other hand, you might renegotiate terms to address the performance of accepted deal. Sometimes, a buying party might requests for changes within deal notes. Examples include adjusting the flight duration, modifying deal terms, updating contact information by adding a new contact object, adding contributing deals, or assigning an upfront. These changes may have restrictions depending on what stage the deal is in.

IMPORTANT: You cannot make revisions to rejected deals and must start a new deal.

What you need to know

Here's what you need to know about revising deals:

• You can revise a deal during any phase.
• When you send a deal revision, it increments the current revision number by one.
• The revised deal starts in the PENDING_ACCEPTANCE status.
• Depending on the types of changes you make, some deals are automatically accepted (such as adding contributing deals or assigning an upfront), while others (such as changes to the deal terms) require acceptance from the buying party before taking effect.
• To communicate with the buying party or additional participants, you can add notes. This doesn't generate a new revision number.

NOTE: Deals that update contributing deals, upfronts, or commitments have additional terms. For details, see Contributing deals, Group deals with upfronts, and Manage commitment deal performance, respectively.

The following sections explain the restrictions that apply to revising deal proposals and active deals. For details on fields in a deal, see Deals object reference.

Deal revision restrictions

When revising the deal terms, some restictions might apply resulting in an error. Some restrictions are dependent on whether the deal is a revised proposal or previously accepted deal. The following table lists the deal terms with restrictions that apply when making a deal revision. For details on fields, see Deals object reference.

IMPORTANT: To add a spend goal to an existing endeavor deal, you must create a new deal.

Revise a deal

To make changes to a deal, use the dealRevise mutation. Here's what you need to know:

• You must include your account ID, deal ID, and contact details as the revising party in the respective accountId, id and updatedBy fields.
• To remove previously set values from the deal, pass null or an empty list.
• Certain fields might result in an error when added to the terms object. For details, see What you need to know.

TIP: Before sending a deal revision, check for feedback or activity from the buying party. For details, see Deal queries.

Here's an example of a dealRevise mutation that extends the deal flight of a proposal:

mutation {
  dealRevise(
    input: {
      id: "DEAL_ID_PLACEHOLDER"
      accountId: "ACCOUNT_ID_PLACEHOLDER"
      terms: {
        endeavorTerms: {
          flight: { 
            endAt: "2025-11-20T04:59:00.000Z",
            timeZone: "UTC"
          }
        }
      }
      updatedBy: {
        name: "Jane Doe"
        email: "janedoe@example.com"
      }
    }
  ) {
    errors {
      ... on MutationError {
        __typename
        message
        field
      }
    }
  }
}

TIP: After revising a deal, keep track of the most recent revision number. For details, see Deal queries.

Auto-accepted revisions

After you send a revision, depending on the terms that have changed, the deal might get auto-accepted. The following changes are automatically accepted and don't require the buying party's approval:

• Deal name
• Display name
• Category taxonomy
• Contact information for either party
• Upfront labels
• Contributing deals

IMPORTANT: Auto-accepted deals still increment the revision number. Be sure to notify your buying party to view the latest changes.

Send deal notes

At any point in the deal life cycle, you can exchange notes with the buying party. However, when a deal has expired or has been canceled, the buying party is unlikely to respond, so avoid sending notes in these cases.

To send messages to the buying party, use the dealNoteCreate mutation. Here's what you need to know:

• Deal notes don't increment the revision number.
• Always include the deal ID and your contact details in the id and createdBy fields.
• Put your message inside the content field.

TIP: You can use notes to inform the buying party of changes and let them know which revision number to review.

The following example dealNoteCreate mutation shows how you can send a message to the buying party to suggest if they should add contributing deals to the primary deal to increase spend.

mutation {
  dealNoteCreate(
    input: {
      id: "DEAL_ID_PLACEHOLDER"
      accountId: "ACCOUNT_ID_PLACEHOLDER"
      content: "Hi Jane, I updated our cancellation terms. See revision number 4."
      createdBy: {
        name: "John Smith"
        email: "johnsmith@example.com"
      }
    }
  ) {
    errors {
      ... on MutationError {
        __typename
        message
        field
      }
    }
  }
}

FAQs

The following are commonly asked questions about deal revision.

How do I revise a deal to add additional buying parties if I cannot modify the buying party?

You can include additional participants from the buy-side in the wseat or advertisers fields within the buyingPermission object of the deal. To remove the buying party from an accepted deal, you must create a new deal.

Should I also add the buying party in the wseat or advertiser field?

No. When you have a buying party listed in the buyingParty field, they can already view the deal, so you shouldn't include their value within the buyingPermission object. By adding a value in the wseat or advertisers fields, you are restricting the deal to only the buying party.