[BUG] Amazon Sp Api is not allowing to add more than one destination

[farid-hussain-qbatch]

Describe the bug I want to add multiple destinations for different subscriptions but it is not allowing me. It says "A destination with arn arn:aws:sqs:us-west-2* already exists for the application amzn1.sp.solution ***" However I am using different ARN with different name.

Screenshots

In simple words it only allows me to add one destination, when ever I try to add second destination, it gives me the same error

[farid-hussain-qbatch]

I am trying to add two different destinations for two different subcription. I want to subscribe notifications for ANY_OFFER_CHANGED and PROCESS_REPORT_FINISHED. Kindly notice in screenshot, that I am trying to add new destinations for different notification type.

[farid-hussain-qbatch]

Please help me out what am I doing wrong here. First I created the destination for ANY_OFFER_CHANGED.

notification.create_destination(name='AnyofferChanged', arn='arn:aws:sqs:us-west-2:*****:AnyOffersChangedQueue')

After that I am trying to create destination for the PROCESS_REPORT_FINISHED, but it is not allowing me.

notification.create_destination(name='ProcessReportFinish', arn='arn:aws:sqs:us-west-2:**:ReportProcessingFinishedQueue')

but it is not allowing me. please help me out.

[farid-hussain-qbatch]

See there is only one destination

[kpconnell]

I can confirm this is now a bug as well. I just got it trying to create a destination on a brand new queue.

[shahviren1985]

I am having same issue. Unable to create new destination.

It seems you can create only one destination for one app in given region. Even if you want to create destination for different sellers it is not possible because the token you create is grantless.

[kpconnell]

I do think this is a change in behavior and or a new bug... I've opened case 9422075841 (North America)

[farid-hussain-qbatch]

Thank you for updating.

[kpconnell]

I do think this is a change in behavior and or a new bug... I've opened case 9422075841 (North America)

Finally made it past the gauntlet of Level 2 support and my ticket is now with engineering.....

[kpconnell]

Also interesting this is occuring on creating either event bridge as well because event bridge you don't actually do anything on your aws account prior to creating the destination... "code": "Conflict", "message": "The requested resource conflict with a resource in the server.", "details": "A destination with arn aws.partner/sellingpartnerapi.amazon.com/xxxx/amzn1.sp.solution.xxx-xx-xx-xx-xx already exists for the application amzn1.sp.solution.xx-xx-xx-xx-xx"

[farid-hussain-qbatch]

Thanks, but I am still waiting for issue to be resolved. Please keep me updating about it.

[alperozhan]

Experiencing the same issue for North America region while creating a new destination.

[zhouzr]

I am having the same issue in fast east region. I got an error when i create destination to receive report processing finished message.

{
  "errors": [
    {
      "code": "Conflict",
      "message": "The requested resource conflict with a resource in the server.",
      "details": "A destination with arn arn:aws:sqs:us-east-1:xxxxxxxxxxxx:xx-xxxx-report-processing-finished already exists for the application amzn1.sellerapps.app.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx"
    }
  ]
}

But I never use this arn in fe, and the response of getDestinations as follow

{
    "payload": [{"resource":{"sqs":{"arn":"arn:aws:sqs:us-east-1:xxxxxxxxxxxx:xx-xxxx-any-offer-changed"},"eventBridge":null},"destinationId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx","name":"ANY_OFFER_CHANGED"}]
  }

[ShivikaK]

Hello,

Thank you for raising this issue.

The error has been reported to our respective engineering team and is currently being investigated. Once the root cause is identified, I will get back to you with further details and next steps to resolve the error. If you have raised a support case with us, please let me know here.

Thanks, Shivika Khare Selling Partner API Developer Support

[zhouzr]

We have raised a support case which ID is 9216407381 about this issue.

[iamricks]

We have opened a case as well, ID: 9475980491

[shuaidd]

I had the same problem

[ShivikaK]

Hello everyone,

Thank you for your patience and understanding.

The root cause for the issue has been identified and the fix has been deployed. Please verify that the error has been resolved and confirm the same for us.

Please note this fix is only for errors encountered when attempting to create multiple destinations for SQS workflow.

For Event Bridge workflow, it is working as designed because there can only be one destination created per AWS account. For multiple destinations, you will need to use different AWS accounts. This functionality will be added in the Notifications Use Case Guide as well.

Thanks, Shivika Khare Selling Partner API Developer Support

[kpconnell]

Resolved for me now.

NOTE: This appears to have modified the behavior of the API a bit:

1) deleteSubscriptionById is no longer grantless* 2) you now cannot have more than one subscription per seller account per type (conflict on createSubscription) (This makes sense..)

• the grantfulness of notifications is going to be highly problematic unless SP-API automatically removes subscriptions when an app gets de-authorized, which I don't think it does. As an app developer, I want to be able to delete subscriptions (and therefore destinations) after I am de-authorized. I will add a feature request.

[alperozhan]

Thanks Shiviva

Issue is resolved for me (us-east-1)

[stefnats]

@kpconnell I think it was not possible to have more than 2 subscriptions per developer per type per seller in MWS either.

[shuaidd]

I had the same problem

Issue is resolved for me

[farid-hussain-qbatch]

Issue has been resolved for me too. Thanks

[ShivikaK]

Resolved for me now.

NOTE: This appears to have modified the behavior of the API a bit:

1. deleteSubscriptionById is no longer grantless*

2. you now cannot have more than one subscription per seller account per type (conflict on createSubscription) (This makes sense..)

* the grantfulness of notifications is going to be highly problematic unless SP-API automatically removes subscriptions  when an app gets de-authorized, which I don't think it does.  As an app developer, I want to be able to delete subscriptions (and therefore destinations) after I am de-authorized.  I will add a feature request.

Hello @kpconnell

We reviewed the deleteSubscriptionById operation and the behavior has not been changed which means that it should still be a grantless operation. If you are facing issues with this API operation, I would request you to open a support case with us to further investigate it.

Thanks, Shivika Khare Selling Partner API Developer Support

[battmush]

@kpconnell I think it was not possible to have more than 2 subscriptions per developer per type per seller in MWS either.

This is absolutely not true: in MWS you were able to have multiple subscriptions for different destinations for single notification types. We're in the process of migrating from MWS to SP-API and are in the situation where attempting to register a second destination for REPORT_PROCESSING_FINISHED notifications yields:

{ "errors": [ { "code": "StateConflict", "message": "The resource specified conflicts with the current state.", "details": "Subscription already exist for notification type REPORT_PROCESSING_FINISHED" } ] }

This is architecture-breaking for our application.

[brinto-evident]

I have an amazon SQS queue for which i created destination using marketplaces US, DE and AU for ORDER_CHANGE notification. When I try to create another destination using the marketplace GB, I am getting this message:

[{'code': 'Conflict', 'message': 'The requested resource conflict with a resource in the server.', 'details': 'A destination with arn arn:aws:sqs:eu-west-2:xxxxxxxxxxxx:order-queue already exists for the application amzn1.sp.solution.xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'}]

How could I possibly solve this?

[abhijeetdighe]

@kpconnell I think it was not possible to have more than 2 subscriptions per developer per type per seller in MWS either.

This is absolutely not true: in MWS you were able to have multiple subscriptions for different destinations for single notification types. We're in the process of migrating from MWS to SP-API and are in the situation where attempting to register a second destination for REPORT_PROCESSING_FINISHED notifications yields:

{ "errors": [ { "code": "StateConflict", "message": "The resource specified conflicts with the current state.", "details": "Subscription already exist for notification type REPORT_PROCESSING_FINISHED" } ] }

This is architecture-breaking for our application.

@battmush We are also facing the same issue, were you able to fix it?

[kpconnell]

There is architecturally no reason for a single application to lean on SP-API to fan out notifications. A single destination per app is completely viable. Fanning it out, for example, in Lambda, is about a 15 minute project.

On Tue, Aug 13, 2024 at 4:50 PM abhijeetdighe @.***> wrote:

@kpconnell https://github.com/kpconnell I think it was not possible to have more than 2 subscriptions per developer per type per seller in MWS either.

This is absolutely not true: in MWS you were able to have multiple subscriptions for different destinations for single notification types. We're in the process of migrating from MWS to SP-API and are in the situation where attempting to register a second destination for REPORT_PROCESSING_FINISHED notifications yields:

{ "errors": [ { "code": "StateConflict", "message": "The resource specified conflicts with the current state.", "details": "Subscription already exist for notification type REPORT_PROCESSING_FINISHED" } ] }

This is architecture-breaking for our application.

@battmush https://github.com/battmush We are also facing the same issue, were you able to fix it?

— Reply to this email directly, view it on GitHub https://github.com/amzn/selling-partner-api-models/issues/2145#issuecomment-2285840890, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHBZWVK5EMQMNXK6HUSXLZRHJGLAVCNFSM6AAAAABIHLER46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVHA2DAOBZGA . You are receiving this because you were mentioned.Message ID: @.***>

[abhijeetdighe]

There is architecturally no reason for a single application to lean on SP-API to fan out notifications. A single destination per app is completely viable. Fanning it out, for example, in Lambda, is about a 15 minute project. … On Tue, Aug 13, 2024 at 4:50 PM abhijeetdighe @.> wrote: @kpconnell https://github.com/kpconnell I think it was not possible to have more than 2 subscriptions per developer per type per seller in MWS either. This is absolutely not true: in MWS you were able to have multiple subscriptions for different destinations for single notification types. We're in the process of migrating from MWS to SP-API and are in the situation where attempting to register a second destination for REPORT_PROCESSING_FINISHED notifications yields: { "errors": [ { "code": "StateConflict", "message": "The resource specified conflicts with the current state.", "details": "Subscription already exist for notification type REPORT_PROCESSING_FINISHED" } ] } This is architecture-breaking for our application. @battmush https://github.com/battmush We are also facing the same issue, were you able to fix it? — Reply to this email directly, view it on GitHub <#2145 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHBZWVK5EMQMNXK6HUSXLZRHJGLAVCNFSM6AAAAABIHLER46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVHA2DAOBZGA . You are receiving this because you were mentioned.Message ID: @.>

We are attempting to register notifications of type ANY_OFFER_CHANGED to a second destination. However we're experiencing a failure of "Subscription already exist for notification type ANY_OFFER_CHANGED". If we delete the subscription to the first destination we're able to subscribe the second destination.

Below are the error details: "code": "StateConflict", "message": "The resource specified conflicts with the current state.", "details": "Subscription already exist for notification type ANY_OFFER_CHANGED"

In our MWS environments we're successfully able to subscribe 3+ destinations to single notification types. We should be able to subscribe multiple destinations to a single notification type.

[abhijeetdighe]

There is architecturally no reason for a single application to lean on SP-API to fan out notifications. A single destination per app is completely viable. Fanning it out, for example, in Lambda, is about a 15 minute project. … On Tue, Aug 13, 2024 at 4:50 PM abhijeetdighe @.> wrote: @kpconnell https://github.com/kpconnell I think it was not possible to have more than 2 subscriptions per developer per type per seller in MWS either. This is absolutely not true: in MWS you were able to have multiple subscriptions for different destinations for single notification types. We're in the process of migrating from MWS to SP-API and are in the situation where attempting to register a second destination for REPORT_PROCESSING_FINISHED notifications yields: { "errors": [ { "code": "StateConflict", "message": "The resource specified conflicts with the current state.", "details": "Subscription already exist for notification type REPORT_PROCESSING_FINISHED" } ] } This is architecture-breaking for our application. @battmush https://github.com/battmush We are also facing the same issue, were you able to fix it? — Reply to this email directly, view it on GitHub <#2145 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHBZWVK5EMQMNXK6HUSXLZRHJGLAVCNFSM6AAAAABIHLER46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVHA2DAOBZGA . You are receiving this because you were mentioned.Message ID: @.>

@kpconnell I see in the Developer Central we are having a single application client. If we create a another new application client will this solve our issue?