Documents and Contracts Public APIs in Sparkforge

If your sales or onboarding process starts in another system, the Sparkforge Documents and Contracts public APIs let you connect that system to your contracts without forcing a human into the Sparkforge UI for every send.

What the APIs cover

The current endpoint set focuses on the core actions teams automate most often:

• List Documents — pull all documents in a location.
• Send Document — deliver an existing document to one or more contacts.
• List Templates — pull reusable templates available in a location.
• Send Template — generate a fresh document from a template and send it in a single call.

List Documents

Use this when an external tool needs to know what already exists in Sparkforge. Common cases:

• Sync document inventory between Sparkforge and another system.
• Show a picker in an internal tool.
• Avoid duplicate creation by checking first.

Send Document

Use this when the document is already prepared in Sparkforge and you only need to push it to a contact at a specific moment. Common triggers from outside Sparkforge include a checkout event, a portal signup, or a custom CRM action.

Three things to keep in mind:

• The document must already exist in Sparkforge.
• Recipient handling follows the official API documentation.
• You can wire workflow follow-ups to fire after the API send is complete.

List Templates

Use this to expose approved templates in an external app — picker UI, internal portal, or partner tool — without rebuilding the content. The endpoint returns the templates available in the location you authenticate against.

Send Template

This is the most useful endpoint for repeatable sends. One call generates a new document from a template and delivers it. Best when:

• You want one canonical template per agreement type.
• Each contact needs a fresh, personalized copy.
• The trigger lives outside Sparkforge but the document infrastructure stays inside it.

Setup

1. Confirm Documents and Contracts is part of your workflow and that the templates you need already exist in the right Sparkforge location.
2. Read the current Sparkforge API documentation to confirm endpoints, auth, and request shapes.
3. Pick the right auth method. Private Integrations work for internal use cases. Marketplace-style developer flows use OAuth.
4. Make sure your requests target the correct location context.
5. Test each endpoint you plan to use: List Documents, Send Document, List Templates, Send Template.
6. Wire workflow automations to document events (sent, viewed, signed, completed) for downstream follow-up.

When to use APIs vs workflows

Workflows are the right tool when the process starts inside Sparkforge and a no-code build is enough. APIs are the right tool when the trigger lives outside Sparkforge or you need custom logic the workflow builder cannot express. The two compose well — an API send plus a workflow that listens for the signed event covers most production scenarios.