UPS Surepost TimeInTransit API - ups

We have had UPS Surepost enabled to our account and a MailerID assigned. However when making POST requests to UPS endpoint: https://onlinetools.ups.com/rest/TimeInTransit we do not get any UPS Surepost services in return. Do we need to add the MailerID to the request somewhere (we have tried with same response). I have tried to reach out to the UPS tech support for documentation and support with no success.
{
"Security":{
"UsernameToken":{
"Username":"XXXXXXXXX",
"Password":"XXXXXXXXX"
},
"UPSServiceAccessToken":{
"AccessLicenseNumber":"XXXXXXXXX"
}
},
"TimeInTransitRequest":{
"Request":{
"RequestAction":""
},
"ShipFrom":{
"Address":{
"AddressLine":null,
"City":"Las Vegas",
"PostalCode":"89103",
"CountryCode":"US",
"ResidentialAddressIndicator":false
}
},
"ShipTo":{
"Address":{
"AddressLine":"XXXXXXXXX",
"City":"Las Vegas",
"PostalCode":"89144",
"CountryCode":"US",
"ResidentialAddressIndicator":true
}
},
"Pickup":{
"Date":"20211118"
},
"InvoiceLineTotal":{
"CurrencyCode":"USD",
"MonetaryValue":"100"
},
"ShipmentWeight":{
"UnitOfMeasurement":{
"Code":"KGS",
"Description":""
},
"Weight":"1"
}
}
}

Related

Why doesn't Autodesk Forge 'workflowAttribute' appear in webhook updates for Model Derivative work?

According to Forge API Reference, there is a workflowAttribute available to 'set some custom workflow information'. Its part of the misc object in the Body Structure of the POST request used to submit a job.
I am using the following request:
convertResponse = await axios({
method: "post",
url:
"https://developer.api.autodesk.com/modelderivative/v2/designdata/job",
headers: {
"Content-Type": "application/json",
Authorization: access_token
},
data: JSON.stringify({
input: { urn: url_safe_encoded_urn },
output: {
destination: { region: "us" },
formats: [
{
type: "svf",
views: ["2d", "3d"],
advanced: { generateMasterViews: true }
}
]
},
misc: {
workflow: "designgen-forge",
workflowAttribute: { projectId }
}
})
});
But when the webHook calls my callback function, I see nothing like hookAttribute available in the data:
{
"version": "1.0",
"resourceUrn": "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6c3VmZm9say1nZW5kZXNpZ25sb3ZlLWRldi10ZW1wLzkxZjhhNGZmLTM5NTYtNGM5Yi05NzkyLThiMWMxNDQyZGJkNyUyRnJldml0LTkxZjhhNGZmLTM5NTYtNGM5Yi05NzkyLThiMWMxNDQyZGJkNy5ydnQ",
"hook": {
"hookId": "6d770063-d5dc-4c66-8ed8-e84207ade07d",
"tenant": "designgen-forge",
"callbackUrl": "https://bigchief.ngrok.io/dev/workitemcomplete",
"createdBy": "9DqOEPqAd4ZZYQ2MAxuT2VQwMfAJrBGp",
"event": "extraction.updated",
"createdDate": "2020-10-20T20:14:31.874+0000",
"system": "derivative",
"creatorType": "Application",
"status": "active",
"scope": {
"workflow": "designgen-forge"
},
"urn": "urn:adsk.webhooks:events.hook:6d770063-d5dc-4c66-8ed8-e84207ade07d",
"__self__": "/systems/derivative/events/extraction.updated/hooks/6d770063-d5dc-4c66-8ed8-e84207ade07d"
},
"payload": {
"TimeStamp": 1603289180515,
"Env": "production",
"URN": "<my urn>",
"EventType": "UPDATED",
"Payload": {
"status": "inprogress",
"bubble": {
"guid": "<my guid>",
"owner": "<my guid>",
"hasThumbnail": "true",
"startedAt": "Wed Oct 21 14:05:39 UTC 2020",
"type": "design",
"urn": "<my urn>",
"success": "75%",
"progress": "50% complete",
"region": "US",
"status": "inprogress",
"children": []
},
"scope": "fd2d74bb-1d5a-407c-a344-20dffa327504",
"registerKey": []
}
}
}
I would imagine that is the intent of the workflowAttribute object to populate something in the callback data, otherwise, whats the point. Am I not specifying it correctly? Or is this not implemented? If not, webhooks become nearly unusable, I suppose the alternative is to make and destroy a webhook for each request, which is so ugly its not really a solution.
Thank you for bringing this to our attention. We could reproduce the issue as well - i.e. that the content of the workflowAttribute provided in the body of POST job request will not show up in the webhook callback.
It's being looked into, and I hope it will work soon, but I cannot yet provide a deadline for that.
In the meantime, the workaround could be either:
a) keep track of the extra data (in your case projectId) associated with the urn of the given file on the server or in a database (you might already be using one)
b) create separate webhooks, as you suggested, with different id for the "scope" -> "workflow" parameter and provide the data as the "hookAttribute" - that will show up in the callback
Update on 2020-12-14: it's working now - see https://forge.autodesk.com/blog/custom-data-translation-webhook

Browse Carousel Card not working for google assistant in Dialogflow

I am trying out browse carousel card (in rich responses) feature available for Google Assistant in Google's Dialogflow.
I am getting only simple response as shown:.
Pasted below the Raw API response (no instances of browse carouse card response).
{
"responseId": "ea913388-8753-458c-b033-396512d1af42-e13762d2",
"queryResult": {
"queryText": "show browse carousel",
"parameters": {},
"allRequiredParamsPresent": true,
"fulfillmentMessages": [
{
"platform": "ACTIONS_ON_GOOGLE",
"simpleResponses": {
"simpleResponses": [
{
"textToSpeech": "sample text"
}
]
}
},
{
"platform": "ACTIONS_ON_GOOGLE"
},
{
"text": {
"text": [
""
]
}
}
],
"intent": {
"name": "projects/leafy-winter-268704/agent/intents/bd457567-02c8-4e15-aca7-c32adfcb45f2",
"displayName": "sampleintent"
},
"intentDetectionConfidence": 1,
"languageCode": "en"
}
}
This is the simulator response. The bot is getting disconnected when an intent with browse carousel is triggered.
Am I doing it in the correct way? what can be done to resolve this issue?
The issue is that you're using a Browse Carousel, but attempting to test it with a Smart Display. Smart Displays don't support links, so they can't support the Browse Carousel.
You can switch to testing it with Android and you should be able to see the Browse Carousel.

Autodesk Forge - Versions GET Downloads returns 400 "Request cannot be handled"

Making 2 and/or 3 legged auth request to Version/GetDownloads returns 400 when VersionId is valid and existing.
When trying to make an http call to a version's download endpoint (https://forge.autodesk.com/en/docs/data/v2/reference/http/projects-project_id-versions-version_id-downloads-GET/), the response returns:
{
"jsonapi": {
"version": "1.0"
},
"errors": [
{
"id": "a306d506-e374-4734-a68e-86c998fc7a5a",
"status": "400",
"code": "BAD_INPUT",
"title": "One or more input values in the request were bad",
"detail": "Request cannot be handled."
}
]
}
This would be ok if the Version Id didn't exist for the corresponding project, but requesting the version's download formats (https://forge.autodesk.com/en/docs/data/v2/reference/http/projects-project_id-versions-version_id-downloadFormats-GET/) returns a 200 response,
despite the version not having any download format:
{
"jsonapi": {
"version": "1.0"
},
"links": {
"self": {
"href": "https://developer.api.autodesk.com/data/v1/projects/{PROJECT_ID}/versions/{URN_VERSION_ID}/downloadFormats"
}
},
"data": {
"type": "downloadFormats",
"id": {URN_VERSION_ID},
"attributes": {
"formats": []
}
}
}
The file I am testing with is a pdf uploaded to BIM360 via the UI. I would have expected to get at least a 200 response on both endpoints. Also, I quite not understand why the downloadFormats endpoint does not return any format.

Can i Use a normal HTTPS rest service for request / response for alexa, not using the alexa SDK

I am creating a normal HTTPS web-service to interact with Alexa. I am able to receive the request in the service and when i am returning response in the same structure as Alexa is expecting! i am getting an error. I am unable to get what's the problem.. the JSON body and Headers are set as per the standards. I am not using lambda, but trying to interact with Alexa with a normal HTTPS service.
Header:
HTTP/1.1 200 ok
content-type = application/json;charset=UTF-8
//Response JSON which is not been identified by alexa
{
"version": "1.0",
"sessionAttribute": {},
"response": {
"outputSpeech": {
"ssml": "<speak> Donut and Coffeee Aussie Style</speak>",
"type": "SSML"
},
"card": {
"content": "to the world",
"title": "Ava"
},
"speechletResponse": {
"outputSpeech": {
"ssml": "<speak>Donut and Coffee Aussie Style</speak>"
},
"card": {
"content": "to the world",
"title": "Ava"
},
"shouldEndSession": "true"
}
}
}
I found what was the problem with my response codes. The fields sessionAttributes speechletResponse are optional fields. The actual field which was missing in above JSON response is the type key value in card response. Even thought the card object itself is optional. If you are using it then you have to have a field called as type in the same. working json response below. Hope this helps the people who are trying to invade the alexa space.
{
"version": "1.0",
"sessionAttribute": {},
"response": {
"outputSpeech": {
"ssml": "<speak> Donut and Coffeee Aussie Style</speak>",
"type": "SSML"
},
"card": {
"type":"Standard",
"content": "to the world",
"title": "Ava"
},
"speechletResponse": {
"outputSpeech": {
"ssml": "<speak>Donut and Coffee Aussie Style</speak>"
},
"card": {
"content": "to the world",
"title": "Ava"
},
"shouldEndSession": "true"
}
}
}

MediaWiki API Incorrect User Rights

I'm battling with the WikiEditor extension of MediaWiki 1.27. When a user tries to use the fancy image upload button from the enhanced editor toolbar, I get the message "You must be logged in to upload files."
So far I've narrowed it down to the user rights returned from the API being incomplete. I've tested with the following two API calls:
The one WikiEditor uses: action=query&meta=userinfo&uiprop=rights
returns:
{
"batchcomplete": "",
"query": {
"userinfo": {
"id": 1006,
"name": "john_smith",
"rights": [
"read",
"createpage",
"createtalk",
"writeapi",
"editmyusercss",
"editmyuserjs",
"viewmywatchlist",
"editmywatchlist",
"viewmyprivateinfo",
"editmyprivateinfo",
"editmyoptions",
"autocreateaccount"
]
}
}
}
However, this API call: action=query&list=users&ususers=john_smith&usprop=rights returns:
{
"batchcomplete": "",
"query": {
"users": [
{
"userid": 1006,
"name": "john_smith",
"rights": [
"block",
"createaccount",
"delete",
"bigdelete",
"deletedhistory",
"deletedtext",
"undelete",
"editinterface",
"editusercss",
"edituserjs",
"editcontentmodel",
"import",
"importupload",
"move",
"move-subpages",
"move-rootuserpages",
"move-categorypages",
"patrol",
"autopatrol",
"protect",
"editprotected",
"rollback",
"upload",
"reupload",
"reupload-shared",
"unwatchedpages",
"autoconfirmed",
"editsemiprotected",
"ipblock-exempt",
"blockemail",
"markbotedits",
"apihighlimits",
"browsearchive",
"noratelimit",
"movefile",
"unblockself",
"suppressredirect",
"mergehistory",
"managechangetags",
"deleterevision",
"read",
"createpage",
"createtalk",
"writeapi",
"editmyusercss",
"editmyuserjs",
"viewmywatchlist",
"editmywatchlist",
"viewmyprivateinfo",
"editmyprivateinfo",
"editmyoptions",
"autocreateaccount",
"edit",
"minoredit",
"purge",
"sendemail",
"applychangetags",
"changetags"
]
}
]
}
}
I'm totally stumped and at a loss of why these two very similar API calls return a different set of rights. As a result, users are not able to upload images via the enhanced editor button.