gitlabEdit

๐Ÿ“ฆRequest Model

Understanding the CompositeRequest structure is essential for working with Docs-Dispatcher. This guide explains required and optional fields, service-specific parameters, and common request patterns.

CompositeRequest Structure

All Dispatcher API endpoints accept a CompositeRequest JSON object with this general structure:

{
  "providerName": "string (optional)",
  "template": {
    "id": "number (required)",
    "data": "object (required)"
  },
  "metadata": "object (optional)",

  // Service-specific fields
  "invoicing": {...},
  "esign": {...},
  "email": {...},
  "sms": {...},
  "postal": {...}
}

Core Fields

These fields are common across all services.

providerName (optional)

Explicitly specify which provider to use for the service.

Type: string

When to use:

  • Override company/user default configuration

  • Multi-provider scenarios (different regions, A/B testing)

  • One-off provider usage

When to omit:

  • Use company default provider

  • Use user override provider

  • Configuration already specifies provider

Valid values: See Provider Configurations

Example:

template (required)

Specifies which template to use and the data to populate it with.

Type: object

Fields:

  • id (number, required) - Template ID from Templater

  • data (object, required) - Template variables as JSON

How to get template ID:

  1. Create template in Templater UI

  2. Or via Dispatcher API: GET /api/v1/templates

  3. Use template ID in dispatch requests

Data schema:

  • Schema is defined per template

  • Use validation endpoint to verify schema compliance

  • See template preview for expected fields

Example:

Webhook URL to receive status updates (async mode) or completion notifications.

Type: string (URL)

When to use:

  • Async mode (?async=true)

  • eSign workflows (signature status updates)

  • Postal tracking updates

  • Long-running operations

Requirements:

  • Must be HTTPS (HTTP not supported)

  • Must return 200 OK within 10 seconds

  • Should handle duplicate events (idempotency)

Webhook payload:

Example:

metadata (optional)

Custom key-value data for tracking and reference.

Type: object

Purpose:

  • Track dispatch origin

  • Link to external system records

  • Add custom business context

  • Filter/search dispatches later

Limitations:

  • Max 20 key-value pairs

  • Keys: max 50 characters

  • Values: max 500 characters

  • No nested objects

Returned in response:

Service-Specific Fields

Different services require different fields.

Invoicing

Required fields:

  • documentType - One of: INVOICE, E_INVOICE, QUOTE, CREDIT

Optional fields:

  • invoicing.dueDate - Payment due date (ISO 8601)

  • invoicing.paymentTerms - Payment terms description

  • invoicing.customerId - Provider's customer ID

  • invoicing.reference - External reference number

Example:

eSign

Required fields:

  • signers - Array of signer objects

Signer object:

  • email (required) - Signer's email address

  • firstName (required) - First name

  • lastName (required) - Last name

  • order (optional) - Signing order (sequential workflow)

Optional fields:

  • esign.signatureType - SIMPLE, ADVANCED, QUALIFIED

  • esign.expiresInDays - Transaction expiry (default: 30)

  • esign.locale - Language code (e.g., fr, en)

Example:

Email

Required fields:

  • email.to - Recipient email (string or array)

  • email.subject - Email subject

Optional fields:

  • email.body - Email body (HTML or plain text)

  • email.cc - CC recipients (array)

  • email.bcc - BCC recipients (array)

  • email.attachGenerated - Attach generated document (default: true)

  • email.replyTo - Reply-to address

Example:

SMS

Required fields:

  • sms.phoneNumber - Recipient phone (E.164 format: +33612345678)

  • sms.message - SMS content

Optional fields:

  • sms.sender - Sender ID (11 chars max, alphanumeric)

Limits:

  • Message: 160 chars (standard), 1530 chars (concatenated)

  • Phone: Must include country code (+33, +1, etc.)

Example:

Postal

Required fields:

  • postal.recipient - Recipient address object

  • postal.recipient.name - Recipient name

  • postal.recipient.address - Street address

  • postal.recipient.city - City

  • postal.recipient.postalCode - Postal/ZIP code

  • postal.recipient.country - Country code (ISO 3166-1 alpha-2)

Optional fields:

  • postal.mailType - SIMPLE, REGISTERED (default: SIMPLE)

  • postal.recipient.company - Company name

  • postal.color - Print in color (default: false)

  • postal.duplex - Double-sided printing (default: false)

Example:

File

Optional fields:

  • file.outputFormat - PDF, DOCX, XLSX (default: PDF)

  • file.filename - Custom filename for download

Example:

Upload

Upload uses multipart/form-data instead of JSON.

Required fields:

  • file - File to upload (multipart field)

Optional fields:

  • metadata - JSON string with custom metadata

Composite Requests (Service Chaining)

Chain multiple services in a single request:

How it works:

  1. Invoicing service generates invoice

  2. Email service sends generated document

  3. Upload service archives document

  4. Returns combined response

Example response:

Common Request Patterns

Pattern 1: Simple Invoice

Generate and send invoice to accounting platform:

Pattern 2: Invoice with Email

Generate invoice and email to customer:

Pattern 3: Async eSign

Send document for signature with webhook notification:

Pattern 4: Tracked Metadata

Dispatch with custom tracking data:

Pattern 5: Document Preview

Generate without external dispatch:

Field Validation

Required Field Errors

Missing required fields return 400 Bad Request:

Invalid Field Errors

Invalid field values return 400 Bad Request:

Type Errors

Wrong data types return 400 Bad Request:

Request Validation

Test requests before dispatch using validation endpoints:

Benefits:

  • Validate structure without external calls

  • Check required fields

  • Verify template data schema

  • No credits charged

  • Fast feedback (< 100ms)

Example:

Success response:

Validation error:

Code Examples

Full Invoice Request (JavaScript)

Full eSign Request (PHP)

Full Postal Request (Java)

Summary

The CompositeRequest model provides:

  1. Flexible provider selection - Default, user override, or explicit

  2. Template-based generation - Reusable templates with dynamic data

  3. Service-specific fields - Each service has unique requirements

  4. Custom tracking - Metadata for business context

  5. Service composition - Chain services in single request

Understanding the request model enables you to build powerful, automated document workflows with Docs-Dispatcher.

Last updated