Support_generateTicketAttachments

Issues short-lived upload credentials so evidence can be uploaded before being attached to a support ticket via its id. Upload each file to its returned url, then pass the returned id values in the evidences argument of Support_createWholesaleSupportTicket.

Supported arguments

The following arguments are supported by Support_generateTicketAttachments mutation:

Return type

Constraints

• qty controls how many upload URLs are generated in a single call. Values less than 1 (0 or negative) are not rejected, they are treated as 1, so a single url is still returned. Values above 20 are capped at 20, so at most 20 urls are returned per call.
• Each returned url is a presigned AWS S3 URL, valid for 15 minutes from the moment it is generated. Request URLs right before you are ready to upload, not far in advance.
• Requesting an id does not upload anything by itself: the API does not check whether a file was actually uploaded before you submit it in evidences. Always upload each file to its matching url (see Uploading a file below) before submitting your ticket, otherwise that report will be missing evidence.

Example usage

Request

mutation GenerateTicketAttachments($input: Support_GenerateTicketAttachmentsInput!) {
  Support_generateTicketAttachments(input: $input) {
    success
    urls {
      id
      url
    }
  }
}

Variables:

{
  "input": {
    "qty": 2
  }
}

Response

{
  "data": {
    "Support_generateTicketAttachments": {
      "success": true,
      "urls": [
        {
          "id": "b1a2c3d4-1234-11ee-be56-0242ac120002",
          "url": "https://marketplace-support-temporary.s3.eu-west-1.amazonaws.com/b1a2c3d4-1234-11ee-be56-0242ac120002?X-Amz-Signature=..."
        },
        {
          "id": "c2b3d4e5-1234-11ee-be56-0242ac120003",
          "url": "https://marketplace-support-temporary.s3.eu-west-1.amazonaws.com/c2b3d4e5-1234-11ee-be56-0242ac120003?X-Amz-Signature=..."
        }
      ]
    }
  }
}

Uploading a file

Each url is a presigned AWS S3 URL scoped to one object and one HTTP method. Upload the raw file bytes with an HTTP PUT request to that url. The file body is all the request needs: no Authorization, Content-Type, or other headers are required, since the query string already carries the AWS SigV4 signature that authorizes the request:

curl -X PUT --data-binary @evidence.png "https://marketplace-support-temporary.s3.eu-west-1.amazonaws.com/b1a2c3d4-1234-11ee-be56-0242ac120002?X-Amz-Signature=..."

A successful upload returns 200 OK with an empty body. Nothing else needs to be called to confirm it: reaching 200 means the file is stored under that id.

Caveats

• Expiry: the url stops working 15 minutes after it was generated. Requesting urls and then uploading much later will fail, so request a fresh batch instead of reusing old ones.
• Method-locked: the signature is only valid for PUT. Using any other method, including GET to try to read the file back afterwards, fails. There is no way to verify the uploaded content through this url, so treat a 200 response as the only success signal.
• Retriable, not one-time-use: the same url can be PUT to more than once before it expires. If an upload is interrupted or times out, simply retry the identical request: the latest successful PUT overwrites whatever was previously stored for that id.
• An extra Content-Type header is not required, but if you send one it is safely stored as the object's metadata rather than breaking the request, since only the host header is part of what was signed.

Error cases

All of these are returned directly by S3 as an XML error body, not by the Eneba GraphQL API. There is no success: false response for upload failures, since the upload itself is a plain HTTP request to S3, separate from the GraphQL mutation.

Once each file has been uploaded, pass the id values in evidences when calling Support_createWholesaleSupportTicket.