When you've queried the first thousand items and maybe you've selected data by a time window, and those little data puddles just aren't cutting it, sometimes you just want it all. Let's talk about paginated requests.
If you're using the GraphQL API and you've seen the new Bulk Send Tool - you might think you'd really like to use that in your automation. You're in luck! Everything done in the bulk tool is handled through the GraphQL API and you can adapt it any way you want.
At the root of why people recommend moving to GraphQL is a concept called 'overfetching', and on the surface, it sounds pretty simple. In many APIs when you inquire about an object, the API returns everything it knows about it, because it doesn't really know what you're interested in. GraphQL (like SQL) lets you tell the API specifically what you're after before it makes the inquiry and returns the data over the network and back to you.
A phrase used in the graphQL best practices is thinking in graphs, part of which
is the ability to access children (and children of children) of the record that you retrieve. As an example, in the Legalesign
schema, a User can belong to many Groups as seen from the user point of view, or seen from the group point of view a Group can
have many User child records.
So you've managed to send off your first few esignature requests using our Quick Start Guide but you can see there's a lot more in the Legalesign API that you'd like to use, but how do you get at it?
Retention rules are a legal requirement for companies handling customer data. In the words of Glen Campbell you've got to know when to hold 'em, know when to fold 'em (or responsibly erase that data, as I'm sure he would have said if it had scanned better).