Delay in Endpoint request

[mehroozkhan]

Hello,
Do you add any kind delay in paging apis ? If yes then how can I change it ?

like its in SWiftyInsta library, and I can change it like handler.settings.delay = 1

Thanks,

[sbertix]

Hey @mehroozkhan,

Starting with Swiftagram 5.3.0, custom delays for paginations (only) are supported again (keep in mind default delay is 0, though).

Here's an example.

var bin: Set<AnyCancellable> = []
let secret: Secret = /* some `Secret` */

Endpoint.user(secret.identifier)
   .posts
   .unlock(with: secret)
   .session(.instagram)
   .pages(.max, delay: 1)
   .catch { _ in Empty() }
   .sink { print($0) }
   .store(in: &bin)

[biox86]

Do you think any kind of delay is needed to avoid temp bans? I experienced that just in case of multiple concurrent requests and if I’m not wrong this shouldn’t happen by default with swiftagram.

[sbertix]

Indeed, multiple concurrent requests should be taken care of by the .instagram URLSession.

Tbh delay doesn't do much. It might for "lower risk" endpoints (e.g. a user's posts or tagged pics), but it just makes things slower for the one people I'm assuming use Swiftagram the most (e.g. followers and following).
The point is, if you start fetching 30 pages of followers, there's no delay that can help: you're gonna get rate limited.

[biox86]

I think that rate limit is still pretty high though. I tested the followers request with an account with 1500+ followers and had no problem. I should try an account with even more to kinda find the limits.

[sbertix]

It's account based: the more you rely on Instagram Private API, and the more you engage in "risky" practices (like getting 30 pages of followers), the more likely your account is to get marked as spam. It was something you could actually check a couple months ago but now they removed it.
This means that 1500 followers might be fine for you, but 100 might be too much for somebody else.
Unfortunately there's not a hard cap on anything, it's all dynamic.

I wouldn't risk pushing it testing it further tbh and compromise an account, when there's no actual need for it.

[biox86]

Nice to know that there’s no hard cap. Feels bad. Lucky for me I implemented a system to check data difference with the previous results to avoid too many requests. I guess it was a nice idea ahah