Synopsis

We've reached a new API limit in https://github.com/WeTransfer/blackbird-api/issues/80. Make sure the community knows this by documenting and explaining what these limits allow you to do.

To Do

• Document limit and explain what you can do with this maximum

Dependencies

https://github.com/WeTransfer/blackbird-api/issues/80

Deliverable

A clear documentation that invites developers to write and test their innovations on our API without limiting them

Content-type: application/json header is a must to use our API, but it isn't documented anywhere, which is a problem when developers don't use our SDKs, and create the requests manually.

It's a minor thing but when I read

content_identifier    String    Yes    Mandatory but must read "file".

it doesn't clearly tell me that the value of this must be file.
Maybe a rephrase like Mandatory must be "file" would be clearer for the reader.
Same goes for the url object.

Is your feature request related to a problem? Please describe.
As per request. The possibility of deleting items inside a board.

Describe the solution you'd like
Make a delete endpoint for deleting items from a board.
e.g. DELETE /v2/board/{id}/file/{id} and DELETE /v2/board/{id}/links/{id}

Based on the ruby-sdk for APIv2, create all code snippets.

Related PR: #72

Hello,

We've tried to activate or update your repository on Depfu and couldn't find any supported dependency files. If we were to guess, we would say that this is not actually a project Depfu supports and has probably been activated by error.

Monorepos

Please note that Depfu currently only searches for your dependency files in the root folder. We do support monorepos and non-root files, but don't auto-detect them. If that's the case with this repo, please send us a quick email with the folder you want Depfu to work on and we'll set it up right away!

How to deactivate the project

• Go to the Settings page of either your own account or the organization you've used
• Go to "Installed Integrations"
• Click the "Configure" button on the Depfu integration
• Remove this repo (WeTransfer/wt-api-docs) from the list of accessible repos.

Please note that using the "All Repositories" setting doesn't make a lot of sense with Depfu.

If you think that this is a mistake

Please let us know by sending an email to [email protected].

This is an automated issue by Depfu. You're getting it because someone configured Depfu to automatically update dependencies on this project.

you cannot delete a file from a transfer, but you can delete something from a board.

To do:

• make the endpoint
• implement lambda function
• document the endpoint

The documentation doesn't explain the expected response codes in a nice way for some endpoints (like /authorize) and is even missing for some of them. We should have an unified way of documenting response codes and response body.

I would suggest to use the following form, as we do for some responses:

Responses

200 (OK)

The Response Body contains the pre-signed S3 upload url.

{
  "url": "https://presigned-s3-put-url"
}

404 (Not found)

If you try to request an upload URL for a file that is not in the transfers, the API will respond with 404 Not found.

{
  "success" : false,
  "message" : "Couldn't find FileObject"
}

417 (Expectation Failed)

If you request to upload part 0, our API will tell you that our parts are numbered for humans; we start counting at part 1:

{
  "success" : false,
  "message" : "Chunk numbers are 1-based"
}

TL;DR See #79 for the parent issue explaining the issue

Test and update all Javascript code examples.

Some code examples aren't working (e.g. faulty request body)

In order to improve adoption of our API, we should run (and fix) all code examples in our JS, Ruby and curl docs.

Implement

• Check and fix Ruby code examples #83,
• Check and fix JavaScript code examples #82,
• Check and fix Shell code examples #84
• Document the file name sanitizer #91
• Add documentation to retrieve transfers's information #81
• Unify response codes documentation #90

and you're done :)

Many developers get stuck using our API because of common errors, like Unsupported Media Type, Unsupported HTTP method, Forbidden, API rate limits, etc.

Adding a section explaining most common errors, and how to solve them, will help them a lot.

We should include a Swagger definition of our API, to make developers life a little bit easier.

A place to provide the relevant documentation for users to easily install a WT embed.

see Uber for example
https://developer.uber.com/docs/riders/ride-requests/tutorials/button/introduction

• Write Documentation
• Make Documentation sections linkable
• Provide clear support for issues

Specify that minimum chunk size is 5MB, when performing multipart upload.

File name sanitizer in the API

In order to not be surprised when uploading a file called 😀or:\.jpg and see it renamed to or.jpg, as an API Consumer I want to have documentation on the file name sanitiser.

Background

Our API is on its way to remove emoji's and some control characters from file names. This behaviour should be made public

See a related PR in the Node SDK: WeTransfer/wt-js-sdk#138

The documentation to retrieve transfer's information is not available, even though we have it for boards. You should make it available so our users can use this feature.

https://wetransfer.github.io/wt-api-docs/index.html#retrieve-boards-information

Synopsis

Document how Public API v1 limits are. See https://github.com/WeTransfer/blackbird-api/issues/55 for implementation.

To Do

Write or change how our limits are affected by that change.

Dependencies

• https://github.com/WeTransfer/blackbird-api/issues/55

Deliverable

See https://github.com/WeTransfer/blackbird-api/issues/46

TL;DR See #79 for the parent issue explaining the issue

Test and update all Ruby code examples.

Is your feature request related to a problem? Please describe.
As per request. The possibility to rearrange the items inside a board. Now the order of items inside the board is the order of it was added.

Describe the solution you'd like
Make a endpoint where you could move items up and down the board.
e.q. /v2/board/{id}/file/{id}/up or /v2/board/{id}/file/{id}/down

@pim found inconsistencies in the curl examples in the docs where sometimes the urls are in quotes and sometimes they aren’t.

Seeing ruby and nodejs sdk I have a feeling that we can add metadata info on our link items and maybe files.
Docs don't seem to support this though https://wetransfer.github.io/wt-api-docs/index.html#add-items-to-a-transfer. I can see only url and content_identifier for link items.
On nodejs sdk (https://github.com/WeTransfer/wt-js-sdk#add-items-to-a-transfer) though I can see that people can add title as their own metadata.

In order to migrate from v1 to v2,
as an sdk developer or API consumer
I'd like to see which boxes I should tick so I will be ready for v2

We need to remove the human intervention part from publishing our docs.

Find a solution to build API docs on merge to master, and display them immediately on our github pages.

It's not clear that the request responses with ({"ok", "message"}) when it either succeeded or failed, and what HTTP response codes to expect

It would be useful for the reader to know if the order of sent items and responded ones is guaranteed.
So if I do the following POST:

curl https://dev.wetransfer.com/v1/transfers/{transfer_id}/items \
  -H "x-api-key: your_api_key" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer jwt_token" \
  -d '{"items": [{"local_identifier": "delightful-cat", "content_identifier": "file", "filename": "kittie.gif", "filesize": 1024}, {"local_identifier": "delightful-dog", "content_identifier": "file", "filename": "puppy.gif", "filesize": 1024}]}'

should i expect that the first item in the returned list will always be for kittie file and second for puppy.
You should make this clear I think so people know if they can script around that logic or not.

Right now it kind of implies that you can PUT the whole file, which is confusing.

Can we add something to the Transfer API that developers can use to alert their users that the link will expire in 7 days.

@arkaitzgarro there is no template for creating an issue here so I'm sorry if this doesn't make sense.

Synopsis

Document how Public API v2 limits are. See https://github.com/WeTransfer/blackbird-api/issues/56 for implementation.

To Do

Write or change how our limits are affected by that change.

Dependencies

• https://github.com/WeTransfer/blackbird-api/issues/56

Deliverable

See https://github.com/WeTransfer/blackbird-api/issues/46

TL;DR See #79 for the parent issue explaining the issue

Test and update all bash code examples.