Child Item

Webhook questions. Also, a way to get actual events?

Dropbox webhooks seem to go conspicuously out of their way to be mysterious in nature. When we receive a webhook, we use a cursor that we're responsible for maintaining to enumerate entries in a directory that the events are supposed to be for, but there appears to be no way of reading the specific events that induced the change. Is there a way of determining if we're receiving the first message versus a duplicate, or are we just keeping track of the ID and version of every file?

I'm assuming that the only way of determine a create versus an update is to check the version, correct?

What does a rename look like? Is a rename considered to be a different operation from a move?

Also, I tried posting this message last night, the forum didn't like any of my tags, and then I got blocked all night for posting the same message more than once in an hour. I'd have complained about it elsewhere, but there's no way to just post website bugs, and the chatbot kept crashing when I selected "Other".

What if there's an update with the exact same data? Does the version change, in this case?

Are we allowed to have duplicate filenames in a single directory?

Is it okay to persist the entry IDs? What about the IDs of files that were deleted? Those events appear to not have the ID, only the name.

I'm confused about managing the various types of account that can induce webhook events based on all of the forum entries I've seen from other eually confused developers. What's the best documentation for understanding how to best manage events from individual accounts versus team accounts?

Is there a simple entry-type name exposed via the Python library? I'm assuming that such a name is probably returned by the API and used by the library to determine which entity classes to use. Do all of the entity classes share a base-class? Are there attributes that we can expect every entry to have? The documentation doesn't do much to expose this.

Thank you.

I find it queer that the documentation and so many of the forum entries reference the ten-second deadline for the response, and yet we're given no information on the actual events and are instead required to go and get the account/team information, lookup our cursor, page through the entries, update the cursor, and return before that deadline. This isn't even processing the data, which can be done asynchronously, but just establishing the minimum information in order to do so. Plus, we have to lock over each account number, in order to properly manage the cursor, which further endangers the deadline. The whole process would be simpler and faster if we just had the information that we're sure to need just given to us directly as well as the actual events that triggered the event rather than only having access to listing directories.

It's the first API for which the adjective "coy" comes to mind.

Also, last night I tried posting this message, but the forum didn't like my tags and then prevented me from posting that first message the rest of the night with the following error: "Post flooding detected (community received posts of a unique message more than 1 times within 3,600 seconds)". I couldn't report it because the website has no general "bug submission" or contact form, and when I tried engaging the chatbot with the "Other" option, it kept telling me it had an error and needed to be restarted.

I just updated this post to include the last paragraph above, and the forum said it saved it but then dropped it. I needed to make the same change twice. The forum software is a little buggy...

Find more posts tagged with

API

Abuse

Comments

Здравко

Hi @dsoprea,

Yes, webhooks can becomes more configurable and let developers configure what they (the hooks) have to provide. The conception instead is different - the idea is just to be a signal that something changes (one or more thing, in one or more accounts). In your code, you have to receive this "signal" and let the web handler return (without actual processing the signal). You can enshedule signal processing in some other thread or entask it in some working queue (or some other asynchronous processing way) - whatever is more convenient for you. To do that, you need to keep/store recursive cursor for entire account's root of every account that's of interest for you. In such a way you can trace any change there with just continue listing updates related to the stored cursor. It's send only one hook call for a file per account, but since a file/folder can be shared - the same file/folder change appears changed in context of more than one account, so you will/can receive the same signal (for a file) more than once! How to handle such cases is matter of your system design. In some cases you don't need to handle such cases in some special way, but in other cases (coming from design decision) you have to.

@dsoprea wrote:
...
I'm assuming that the only way of determine a create versus an update is to check the version, correct?
...

Again, It's matter of the design what you need to keep/trace for particular file (including even if you need to do such things at all).

@dsoprea wrote:
...
What does a rename look like? Is a rename considered to be a different operation from a move?
...

In general it's the same thing. For business account, if it's of interest for you, some distinctions can be made based on system logs. It's your decision about using such features when available.

@dsoprea wrote:
...
Also, I tried posting this message last night, the forum didn't like any of my tags, and then I got blocked all night for posting the same message more than once in an hour. I'd have complained about it elsewhere, but there's no way to just post website bugs, and the chatbot kept crashing when I selected "Other".
...
Also, last night I tried posting this message, but the forum didn't like my tags and then prevented me from posting that first message the rest of the night with the following error: "Post flooding detected (community received posts of a unique message more than 1 times within 3,600 seconds)". I couldn't report it because the website has no general "bug submission" or contact form, and when I tried engaging the chatbot with the "Other" option, it kept telling me it had an error and needed to be restarted.

I just updated this post to include the last paragraph above, and the forum said it saved it but then dropped it. I needed to make the same change twice. The forum software is a little buggy...

Unfortunately you're correct. 🤷 There are lots of bugs in this forum and the mentioned by you (buggy spam detector) is just one of them. Yes, the chatbot is in fact useless. I'm not sure I can enumerate all bugs, but one simple example (that can be seen all around) is that number of post's pages (for users that have more than 10 posts) is not enough for all posts. 😁 Isn't funny? Seems the web designer doesn't know about difference between zero based and one based indexing. 🙂 In such a way some posts can let "hidden".

@dsoprea wrote:
...
What if there's an update with the exact same data? Does the version change, in this case?
...

Update with exact same data is ignored - so there isn't update in fact.

@dsoprea wrote:
...
Are we allowed to have duplicate filenames in a single directory?
...

Good question! As in any local filesystem there are not allowed duplicate file/folder names residing in a single directory. Unfortunately, Dropbox keep count different name casing as the same things (despite of many filesystems in use - most of the filesystems in use actually - don't do that), so Dropbox doesn't let files/folders in the same directory that differ only by letter casing. 🤦 This is a predisposal for conflicts with locally saved files/folders (and online processing too). Most other providers don't have this "bug". 🤷 You have to take this in mind in your system design if you want to cooperate troubleless with Dropbox.

@dsoprea wrote:
...
Is it okay to persist the entry IDs? What about the IDs of files that were deleted? Those events appear to not have the ID, only the name.
...

😁 Ha ha... A good note! Actually there are ID for deleted files too. They just don't appear in listing these files, unfortunately. You have to handle only the names as a initial identifier for deleted files/folders.

@dsoprea wrote:
...
I'm confused about managing the various types of account that can induce webhook events based on all of the forum entries I've seen from other eually confused developers. What's the best documentation for understanding how to best manage events from individual accounts versus team accounts?
...

As I noticed above, all webhooks are just signals that something in particular context(s) has been changed (one or more contexts and/or things). For general description take a look here. For Team accounts specifics take a look here.

@dsoprea wrote:

Is there a simple entry-type name exposed via the Python library? I'm assuming that such a name is probably returned by the API and used by the library to determine which entity classes to use. Do all of the entity classes share a base-class? Are there attributes that we can expect every entry to have? The documentation doesn't do much to expose this.
...

There isn't any documented entry-type that any particular SDK (including Python SDK) should return as a base type of everything. In spite Python has its own base type of everything - Object. 😉 You don't need more actually. You can always check whatever you need based on the description of particular results/exceptions methods.

Hope this clarifies matter.