If you're a developer, you know REST. For many years, REST has been the dominant approach. You'll also know that GraphQL hasn't taken over, REST is as strong as ever.

So no, you don't have to use GraphQL and Legalesign won't drop REST any time soon. But if you gravitate to REST only because you already know it, take a moment to consider GraphQL. It's here and may help you as you dive deeper into your integration.

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.

What's a Connection?​

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).