- Your account cannot be activated until it has a storage destination that works.
- An editor session of any kind cannot be made without one. The call answers
409withPARTNER_STORAGE_REQUIRED. - An upload of your own, whichever way you make it, is refused the same way while you have no destination. A resumable upload is refused when it is declared, before the first byte is sent. Nothing is ever stored with Widgetic instead.
What You Need
- A bucket on an S3-compatible service.
- An access key that may put objects into it. It may also delete objects, which lets Widgetic clean up the test file, but that is not required.
- A public address the stored files are served from: the bucket’s own public address, or a CDN in front of it. Your customers’ browsers read the files from there, so the bucket, or the CDN, has to be publicly readable.
Set It Up
You need the id of your partner record (GET /partners/mine gives it, see Account Status) and an API key with full access. Saving a destination is a PUT, and it replaces the whole destination, so send every field again, the secret included.
The request fields are snake_case, like the rest of the upload calls. The answer is camelCase and never holds the secret. It shows the last four characters of the access key id as
accessKeyHint, so you can tell which key is set:
The Check
A destination is checked before it is saved, so a destination that does not work is never saved. Widgetic does what an upload will do, in this order:endpoint. The service host resolves to public addresses only.write. A small test file is written under<key_prefix>widgetic-check/.public_read. The test file is read back from<public_base_url>/<its key>and must be exactly what was written. This is what proves the address your customers use serves the file.
422 with the step, a stable code and the field most likely to be wrong:
details.step is endpoint, write or public_read. details.reason is the stable code to switch on; the message is a fixed sentence and never repeats anything from your storage’s own answer.
Keep It Healthy
GET /partners/{partnerId}/storagereturns the destination without its secret: when it last passed the check (verifiedAt) and, if a later check failed, why (lastVerificationError). It answers404while you have none.POST /partners/{partnerId}/storage/verifyruns the check again against what is saved. Use it after you rotate a key or change a bucket policy, or when uploads fail with502or503. A pass refreshesverifiedAt. A failure answers422as above and is recorded, but it does not remove the destination or stop uploads from using it. You are told about it with astorage.check_failednotification, once a day at most however often you run the check.DELETE /partners/{partnerId}/storageremoves the destination. After that your customers’ uploads and your own are refused with409PARTNER_STORAGE_REQUIREDuntil you save a destination again, and no editor session can be made. Files already in the bucket are not touched and not moved: they stay where they are, at the addresses they were given, and keep working for as long as the bucket stays publicly readable.
What Goes Where
A partner account has no storage allowance. What is kept in your bucket takes none of Widgetic’s, and Widgetic does not sell extra storage to a partner account (see Credits & Billing). The upload call and the customer’s own filing are described in Managed Users.
When a destination is set, an upload is never stored with Widgetic instead of in it. If the destination cannot be used, the upload is refused (
503), and if your bucket rejects the file, the answer is 502. The customer reads one plain sentence, “This is not available right now. Please try again later.”, that names neither your storage nor a limit, because it is your setup and not theirs.
What Each Customer Keeps
GET /partners/{partnerId}/storage/usage says how many files and how many bytes your account keeps: in total, and for each of your managed users, split into what is in your own bucket and what is with Widgetic. The groups are ordered by size, the heaviest first. It is counted when you ask, so it is always current. Use it to see which customers store the most, or to charge them for it.
managed_user_id or managed_user_external_id when you upload it, or because it came through that customer’s editor session, which files everything under them. The row whose managedUserId is null holds the files that are not filed under anyone: your own, and the ones you uploaded without naming a customer. Deleted files are not counted. To list the files of one customer, use the managed_user_id filter of GET /uploads. The dashboard shows the same figures next to each customer (see Partner Dashboard).
The call needs the partner:read scope when your key is limited to some scopes (see Authentication).
Errors
Account Status
Activation needs a storage destination that works
Editor Sessions
Where your customers’ uploads come from