cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
570
Views
1
Helpful
5
Replies

Post Mashery migration bug: Missing 'party id'

DanJ
Level 1
Level 1

After the migration from Mulesoft to Mashery, I have updated the request URLs to point towards apix.cisco.com (before apx.cisco.com).

Requests mostly work as intended, but I randomly recieve the following error message:

{
    "status": 400,
    "message": "Invalid input request",
    "reason": {
        "errorCode": "API_INV_000",
        "errorInfo": "Missing 'Party id'. Party Id is required in request header"
    }
}

This occurs for every single services API endpoint I poll for data. (HW Inventories, SW inventories, product alerts, coverage etc). It seems to happen totally at random. I would say 3/5 requests go through at average, while the rest fails with the party id error.

Meaning I can run this 5 times in a row, and usually get 2 errors and 3 success with no changes to the request (identical request, different outcome).

Looking through the services API documentation, there is no such request parameter as "party id". This error message tells me absolutely nothing.

I have been using the services API for over a year now, and have never seen this error before after I migrated to Mashery. Therefore I suspect there must be something wrong with the new Mashery platform.

Please advise

1 Accepted Solution

Accepted Solutions

Ralph Herbst
Cisco Employee
Cisco Employee

A update was performed Feb 2, 2024. This issue should be resolved.

View solution in original post

5 Replies 5

danail.petrov
Level 1
Level 1

FWIW - I seem to observe exactly the same behaviour where I have scheduled tasks that run daily and I get sporadic results every now and then. The issue seem to have started end of November, which also aligns with the MuleSoft -> Mashery migration. 

Thank you for your reply.

I have tested the API using Postman, and I recieve the same error. So it is definitely not something with my code.

I do hope this will be fixed soon though..

I have (empirically) established that if I re-run the same request again - the second one always goes through. I don't know how long this period is currently going for (in between 1st and 2nd run) but it almost seems like some "data warming - up" is needed every so often.. 

Ralph Herbst
Cisco Employee
Cisco Employee

A update was performed Feb 2, 2024. This issue should be resolved.

Tested this morning and was able to submit several requests in sequence without any error. This was previously highly unlikely if not impossible to achieve.

 

Seems to be resolved