Integrations

Connect document workflows
to their destination

Start from a connector when the action already exists. Use REST, an SDK, a signed webhook, or MCP when your application or assistant needs to control the workflow.

Start Free API Reference

Free account, no credit card

Find the action your destination supports

Search for the CRM, accounting package, messaging tool, or storage service already in the workflow. The directory contains 732 connectors and 727 named actions, so you can verify what a connection does before configuring it. Pay attention to whether the action creates, updates, sends, or uploads: those verbs define the destination effect and the fields you will need to map.

732 connectors carry 727 named actions between them, each firing when a submission arrives. Try one:

If the destination is not listed, call the REST API from your application or accept a signed webhook at an HTTP endpoint. Storage delivery can also place a finished file in a configured S3, Google Cloud Storage, or Azure destination without a business-app connector.

Browse connectors by workflow category

10 categories organize 399 of the 732 connectors by the work they support. Open a category to compare the tools and named actions that belong to that part of the workflow.

Generate the file before handing it to the destination

A submission can start document generation, then route the completed file to storage or a connected system. Each stage has its own result, so your workflow can distinguish a render failure from a destination that rejected delivery.

Submission Document Connector Their system Your bucket

The render job and the connector action are separate states. Keep the job ID with your source record, then use the returned status to decide whether to retry delivery, correct the input, or send the failure to an operations queue.

Read the verb before choosing the connector

A familiar logo does not prove that the action you need exists. The directory records 727 named actions. These four common prefixes show the kinds of work represented, while the finder above gives the exact action for each tool.

Create: 446 actions

Create a contact, lead, row, ticket, invoice, or other new record from submitted data. Check the destination action to see which fields it accepts and what it returns.

Add: 93 actions

Add a contact, subscriber, member, or item to a list that already exists. These actions fit workflows where the destination owns the container and Cloudlayer supplies the entry.

Send: 70 actions

Send an email, text, notification, or other message when the destination exposes that action. Whether a file can be attached is specific to the connector contract.

Update: 24 actions

Change an existing destination record instead of creating another one. Use the action's matching field or identifier to make the intended record explicit.

Other actions subscribe, register, upload, convert, or start a destination workflow. Search the tool by name and confirm the recorded verb before treating it as part of your design.

Keep generation and delivery in one observable workflow

Moving fields between systems is only part of a document workflow. Cloudlayer can apply the data to a saved template, render the file, record the job outcome, and then pass that result to a destination with a matching action.

  1. Start with the source event. A hosted form, application request, connector event, or agent tool call supplies the data. Preserve its identifier so the resulting document can be traced back to the input.
  2. Render from an approved template. Map source fields to template variables and keep layout rules in the template. The job result tells the workflow whether a file was produced or the render failed.
  3. Choose a destination action that accepts the result. Some connectors create or update records, while others send messages or upload files. Confirm the exact action rather than assuming every connector can carry an attachment.
  4. Use an open integration path when no connector fits. Call REST from the system that owns the data, receive a signed webhook at your endpoint, or configure supported object storage as the file destination.

Four integration patterns to adapt

Start with the event, the document, and the destination. These examples show how the pieces fit without promising that every named system exposes every possible action.

Sales: quote to signed contract

A form or application supplies quote data, a template renders it, and a signing workflow collects approval. Then use a supported CRM action or webhook to record the outcome.

Finance: submission to invoice

An order event supplies customer and line-item data. Generate the invoice, then call the accounting action that creates the required record or delivers the file.

Operations: record and notify

An inspection submission produces a report. Store the file in the configured bucket, write the tracking data to a supported system, and notify the team through another action.

Marketing: capture and enroll

A registration form produces a confirmation document. Add the person to a supported audience or list, then use mapped fields to preserve the choices needed for follow-up.

Choose the boundary your workflow needs

Connectors, REST, webhooks, and MCP all reach the same document platform from different callers. Choose based on who owns the trigger, where the data lives, and whether the result is synchronous or asynchronous.

Connector: the named action already fits

Configure a listed action without deploying application code. This is useful when the source fields already match the destination and the process owner can maintain the mapping.

REST or SDK: your application owns the logic

Call the HTTP API directly or use a public SDK when the source data is already in your backend. Your code chooses the template, render options, response mode, and destination.

Webhook: react when async work finishes

Verify the signed callback and correlate it with the stored job ID. Your service can process the result or failure without keeping the original request connection open.

MCP: a compatible assistant is the caller

Grant a compatible client scoped access to document tools. The assistant can select an existing template, start a render, and inspect job state within those permissions.

Know where a connector stops

A connector saves request code for a known action. It does not remove the destination's schema, limits, authentication, or failure modes.

  1. Field mapping is not arbitrary application logic. Use the API or an intermediate workflow step when a value must be computed, looked up, validated against another system, or transformed beyond the connector's mapping controls.
  2. The available trigger is part of the contract. Submission-driven actions react to a submission. For scheduled or application-owned events, start the document through the relevant scheduler, REST call, or supported trigger instead.
  3. Destination limits still apply. A connector action can be throttled or rejected by the other vendor. Surface the result, apply bounded retries where appropriate, and avoid assuming storage delivery is unlimited.
  4. The source of truth should start the workflow. When another application decides that a document should exist, let that application call REST or an SDK. Do not introduce a form submission only to create a trigger.
  5. A connector is one path, not the data model. Keep templates and source data understandable outside the connector. REST, webhooks, and owned storage remain available when the workflow outgrows a packaged action.

Test the handoff, not only the render

A valid PDF does not prove the complete integration works. Before production, exercise the identity, size, retry, and reconciliation behavior at the boundary between Cloudlayer and the destination. These checks apply whether that boundary is a connector, webhook, API response, or storage provider.

Use a stable correlation ID

Store the Cloudlayer job ID beside the source submission or application record. Include your own identifier where the destination permits it. When a user reports a missing document, both sides of the handoff can then be inspected without matching on filenames or timestamps.

Send a realistic file

Test the page count, attachment size, filename, and content type your production workflow will create. A connector that accepts a one-page sample may still enforce a destination limit when the real report contains images or many pages.

Repeat the same event safely

Simulate a timeout after the destination accepts the request. Decide whether replaying the action should update the existing record, create another one, or stop behind an idempotency key. The correct behavior depends on the selected action.

Make a failed delivery visible

Reject a test request at the destination and confirm that the workflow records the failure, preserves the render job, and alerts the owner who can act on it. A retry policy is useful only when exhausted attempts lead somewhere observable.

Build the template and choose its caller

Visual editor

Build the reusable layout in the browser. Place text, images, and variables on the canvas, or open the underlying HTML and CSS when the design needs code-level control.

Open the editor

Zapier

Configure a supported trigger and map its fields into document generation through a visual workflow. Check the Zapier page for the available Cloudlayer events and actions.

See the Zapier workflow

REST API

Send HTML, a template ID, or a URL to JSON endpoints for PDF and image generation. Choose a synchronous response or an asynchronous job based on the surrounding application flow.

Read the API documentation

SDKs and libraries

Use a public client for .NET, F#, Go, Java, JavaScript, PHP, Python, and Ruby, or call the REST contract from another language.

Choose an SDK quickstart

Operational pieces around the connection

Webhook delivery

Receive signed success or failure events for asynchronous jobs, then use the job ID to retrieve and reconcile the result.

Managed template assets

Upload fonts, images, and stylesheets once and reference their stable URLs from templates and render requests.

Template revisions

Keep document layout in a managed template so content and design changes do not require an application deployment.

Several output formats

Request PDF, PNG, JPEG, or WebP output from the same source template according to the destination's needs.

Response and delivery choices

Handle bytes, base64 content, a hosted result, webhook delivery, or configured storage without changing the document layout.

Bounded concurrency

Use plan concurrency, async queues, retry guidance, and job status to keep bursts from becoming untracked work.

Connect one complete document path

1

Prepare the template

Clone a gallery design or build your own, then identify the variables the source system will supply.

2

Choose the caller

Configure a connector, install an SDK, call REST, or grant an MCP client only the access the workflow needs.

3

Handle every outcome

Store job IDs, verify webhook signatures, and define what should happen when rendering or destination delivery fails.

8
Official SDKs
Available on GitHub
36
Payment gateways
Accept payments on forms
6
E-signature providers
Triggered from submissions

Questions about document integrations

How many tools can you connect to?

We support 732 connectors with 727 automated actions. You can search the directory below to explore actions by app. If your specific system is not listed, you can easily connect via our REST API, official SDKs, or signed webhooks.

Does the generated document travel with the data?

A workflow can generate the file first, then deliver it to a connected system or cloud storage. The exact attachment behavior depends on the connector action you choose, so check the action list for that destination before building the workflow.

What happens when a connector is rate limited?

A destination can reject or throttle an action according to its own API policy. The workflow surfaces that failure, and configurable retries can handle conditions likely to recover. For async document work, job state remains available through the Jobs API even if a delivery step fails.

Can an AI assistant call this directly?

Yes. The remote MCP server exposes document and template operations as tools. An authenticated assistant can use the templates and permissions available to that connection, then start and inspect render jobs.

Which integration should I start with?

Use a connector when a listed action already matches the workflow. Use the REST API or an SDK when your application owns the data and business logic. Use webhooks when the result should return after an asynchronous job finishes.

Do I need an API key for the no-code path?

The connection needs authorized Cloudlayer credentials. After it is connected, you can select a template and map fields in the workflow editor without writing request code.

Can AI tools generate documents for me?

Compatible MCP clients can connect to the remote server, subject to authentication and granted scopes. The available tools can browse templates, start renders, and inspect jobs.

Which languages have official SDKs?

.NET, F#, Go, Java, JavaScript, PHP, Python, and Ruby. They call the same REST API, with language-specific request and response handling.

Connect one document workflow
from source to destination

Choose a template, verify the action or API contract, and test both the successful file and the failure path before production.

Start Free

No credit card required.