I’m working on a tap that has a few ‘synchronizati...
# singer-tap-development
n
I’m working on a tap that has a few ‘synchronization’ endpoints. The intended flow from the API developers is: • Request id’s and versions (with GET) • Compare them against current, stored versions in the target • Request new or updated id’s (multiple, max 100) (with POST - same endpoint) The maximum number of records in the biggest endpoint is about 2.500, so not really much. I could do a full load each time (if that’s easier). How could I handle this case? Example endpoint: https://developer.moneybird.com/api/documents_general_journal_documents/#get_documents_general_journal_documents_synchronization
a
I would look into the
filter
option here, meltano can manage the state of when you last queried the API, and then use that to only retrieve the changed records if you can filter via
updated_at
timestamp. https://developer.moneybird.com/api/documents_general_journal_documents/#get_documents_general_journal_documents_synchronization_example1 You're not going to be able to send the specific IDs to request without some serious dev work.
n
Hi Andy, thanks for the response. The problem with the filter option is that it can only return a maximum of 100 records. If the selection is bigger (and it will be in the first selection), it will fail.
{
"error": "Too many financial mutations to return, please use sync API"
}
a
The docs aren't super clear, but it looks like the restriction only applied when you are specifying IDs? Does it also apply if you use
synchronization.json?filter=period%3Athis_month
too?
If so, and you are expecting high volumes, full table looks like a simpler approach if you can throttle appropriately. Docs don't specify what options you have for
period
filtering.
n
/financial_mutations?filter=period:prev_year
results in:
{
"error": "Too many financial mutations to return, please use sync API"
}
👀 1
a
Well... one option would to be to batch up your requests to a shorter period. For example, if you need a weeks worth of updates, split that into 7 separate requests for each day.
n
Yeah, maybe I should traverse a list with periods (202501..202501 is valid for example). And just call the endpoint for eacht month.
a
Yes, you could even do something clever like requesting a week, and if that fails with the error, step down to day level etc.
n
👀 1
a
OK I would take the 'day by day' approach. Are you expecting to hit the limit fairly often, or are you just coding for 'in case'?
👍 1
n
Yeah, that should work out. Thanks.
I don't think we will hit the limit often.