Streams API - Get the Content of a Stream - Max Count changed?

[Jon Lee]

Did the count parameter's maximum value change recently? I feel like it used to be 1000, but I now see 250.

API Docs: https://developer.feedly.com/v3/streams/#get-the-content-of-a-stream

Also, is there a log of what changes are made to the APIs?

[David Chatenay]

  Hi Jon,

  The maximum is variable and depends on the stream type and options, but 250 is indeed the maximum right now.

  I will update the documentation accordingly.

  There's a basic changelog available but it only lists the major changes.

  Best regards,

-- 

David Chatenay

Platform Engineer

Feedly

--
You received this message because you are subscribed to the Google Groups "Feedly Cloud" group.
To unsubscribe from this group and stop receiving emails from it, send an email to feedly-cloud...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/feedly-cloud/c3d95e33-007f-45d7-9713-bfc6e2e471dcn%40googlegroups.com.

[Jon Lee]

Hi David,

So is the max 250 count for all types of streams? Or more specifically, what are the max count for:

1. Stream IDs coming from Enterprise Collections: ?

2. Stream IDs coming from Enterprise Priorities: ?

Thanks,

Jon

[David Chatenay]

  It's 250 for both of these, unless you pass `similar=true` (which adds duplicates properties): it goes down to 100 in that case, because finding duplicates is an expensive operation.

  You will need to use `continuation` to fetch additional pages.

-- 

David Chatenay

Platform Engineer

Feedly

To view this discussion on the web visit https://groups.google.com/d/msgid/feedly-cloud/7837c013-4d1e-4d6c-9771-b521d5e73df7n%40googlegroups.com.

[Jon Lee]

Thanks for confirming that.

In my history, I've had Stream IDs coming from Enterprise Priorities retrieving 1000 for max count. Was it ever indeed 1000 or has it always been 250?

[David Chatenay]

  It used to be 1,000 for a long time, but we noticed a lot of API abuse, as well as inefficient use e.g. re-loading the entire feed history every time the customer logs in instead of relying on newerThan and pagination. In the case of priorities and special streams, it was also very taxing on the server, and sometimes resulted in timeouts.

  So we've lowered the max to provide a smoother experience.

-- 

David Chatenay

Platform Engineer

Feedly

To view this discussion on the web visit https://groups.google.com/d/msgid/feedly-cloud/3c65f3ac-98a3-44aa-83e7-94fdaa92e602n%40googlegroups.com.

[Jon Lee]

I see, that makes a lot of sense.

Somewhat tangential question...

I just noticed that the continuation parameter can accept a ms timestamp (similar to newerThan). Is this a new feature? I feel like I haven't seen that tidbit in the docs before.

Am I right in concluding that using continuation + newerThan would let me filter for entries between the bounds without having to paginate from most recent to oldest? 

i.e) act as continuation + newerThan could be like a "Get entries between X and Y date".

[David Chatenay]

  Hi Jonathan,

  Yes `continuation` indeed accepts timestamps. It can thus be used as an `older than` limit of sorts.

  Also recently added: `newerThan` accepts negative numbers to simplify syncing and avoid client/server clock differences. E.g. `newerThan=-3600000` indicates you only want articles added in the past hour (the value is in milliseconds, as usual).

  You could in theory pass EPOCH timestamps in `newerThan` and `continuation` to fetch a "time slice", as long as these values are within the past 31 days (which is the limit for `newerThan`).

  Hope this helps,

-- 

David Chatenay

Platform Engineer

Feedly

To view this discussion on the web visit https://groups.google.com/d/msgid/feedly-cloud/c2f213f1-dc15-42fe-9fc0-3d778ee755a7n%40googlegroups.com.

[Jon Lee]

Wow, that's a wonderful upgrade!

Thanks for all the information! I'm sure a lot more users would benefit from this if the docs mentioned these.