While building the “trigger” part of a Zapier integration, I am sending an array of objects being developed on fly using the DB layer behind the back-end API. But I don’t want to send a huge array covering all the rows of a particular table (say recipes), What I understand Zapier expects the array of  ~ 25 objects (got this number from a video by Zapier’s Engineering Manager) and it will figure out the new entries and accordingly will trigger the “trigger”. But this raises the question what if we have more than 25 or may be 100s of objects being added between 2 polls of Zapier, how to handle such situation?

Should I keep track of the id number to which we have submitted to Zapier and send array of objects only beyond that id? If this is the recommended practice what can be good architecture philosophy to implement the same, I mean what are the best practices to do this?

I would like to know the brief architecture of the Zapier, particularly the trigger part so that we can plan the integration in a better way. Zapier has done a remarkable job with good documentation and even good starting point example integration apps on GitHub but I couldn’t find much information on best practices for constructing integrations. If you do have something (some web-link / tutorial etc) please mention.

I have one more related concern, for triggers coming from the application/API, Zapier shall be storing the data in clear text? How Zapier secures this data and make sure there are no security breaches?