Further investigation around number of funding instruments and 503 error

[John_Developer]

Continuing the discussion from 503 error occurring seemingly connected with mobile_conversion_re_engages metric:

Thank you for your response on this. I have done some further investigation and agree that reducing the number of funding instruments in the request does stop the error. In the request I posted there are 18 funding instruments. I have found that the crossover point between getting the 503 error and not getting it is about 7 or 8, i.e. I can run the code successfully by batching this up to about 8 per request, but not thereafter.

However I’m not entirely convinced yet that this is only a matter of requesting too much information and therefore hitting rate limits. Specifically I’d like to raise the following points:

• Why is this showing up as a 503 error rather than 429, as we’d expect for rate limiting issues?
• Why does this only affect account d80pk and not any others?
• Why does the issue only appear on inclusion of one specific metric?
• Connected with the above two points, how is it that we have to reduce the number of funding instruments per request so significantly in this one very specific case before it works? This is the main point – the circumstances around the failure seem too specific to be explained only by requesting too much data.

I can certainly change our code to ensure we minimise the number of funding instruments we include in a single request, but I feel that there might be something else going on here which is not yet explained.

Apologies if I’ve misunderstood something about how this works, but please can you let me know if you have any further advice on this, many thanks.

[brandonmblack]

The API has a hard limit on the time it takes the service any request. Even if you’re under the limits in terms of number of items you’re allowed to return from a given API, no request to any Twitter API (no just the Ad API) can exceed 4.5 seconds total.

If you exceed that time limit, the server is deigned to interrupt the the request and return a 503. This prevents expensive, long-running requests from impacting other developers by consuming too much compute time or hanging.

Funding instruments are high-level items that sit at the top of the Ads platform object hierarchy and as a result they’re a bit more expensive than you might think to return. This is why our best practices recommend pulling at the line item or promoted tweet level, storing that and then rolling it up into the funding instrument level. If you continue to pull at the funding instrument level, you’ll quickly use up all your capacity and if there’s too much data (as John already mentioned in his answer to you) or it takes to long to fetch the data the server will refuse your request as you’re seeing now with the 503s.

You should take a look at our Analytics Best Practices and make sure you’re actually following the guidance there. Those suggestions are there for a reason and the approach you’re currently taking won’t be successful for you as you scale out your build (as you’re already seeing).

Additionally, please take a moment to re-read our Guidelines for Reporting issues. Specifically, please don’t duplicate threads where you’ve already been answered and make sure you include enough information for us to reproduce your issue and research it further if needed.

Closing this thread as duplicate:

503 error occurring seemingly connected with mobile_conversion_re_engages metric

I don't know whether this is a bug or not, but I'm experiencing a 503 error when calling the GET stats/accounts/:account_id/funding_instruments endpoint. The error only occurs for this endpoint (our application calls 12 endpoints in total), and it also only occurs for 1 of the 3 accounts we're currently testing with. We supply a large number of metrics to this call, and following some investigation I've established that the inclusion of the mobile_conversion_re_engages metric is the sole cause, …

[brandonmblack]

This topic was automatically closed after 24 hours. New replies are no longer allowed.