Cloud Login
Free Trial

Cloud

document generation software as a service

A reliable, multi-region, cloud-based web service and document generation API .

docmosis cloud
  • Get started fast, with nothing to download/install/run.
  • Usage based pricing, starting from $49/mth.
  • Use Docmosis as a service via a simple REST API.
docmosis cloud

A Cloud Document Generation API

Any web connected application can use the service to generate documents.

Cloud Document Generation API
The Cloud document generation service has been engineered to take full advantage of modern cloud computing concepts. Running on AWS, the service is distributed over multiple regions and availability zones. Under load the processing scales across multiple servers to provide a high-availability and reliable service.

The Cloud also provides a convenient web portal, useful for initial evaluation and ongoing template/account/billing/user management.

The service has been designed to efficiently perform transactional requests, generating single-page documents sub-second, or to meet large batch processing requirements and is capable of generating hundreds-of-thousands of documents-per-hour.

Cloud Document Generation API

# Use the Docmosis Cloud service running in the US region
url = URI(“https://us1.dws4.docmosis.com/api/render”)
http = Net::HTTP.new(url.host, url.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE

# Specify data to be merged with the template
JSON_DATA='{“message”:”This doc gen API is working great!”}’;

# Create the POST request
request = Net::HTTP::Post.new(url)
request[“Content-Type”] = ‘application/json’

# Add accessKey, data, template and output file / format to the request
request.body = “{” +
“\”accessKey\”: Y2QxNj1hMzYtOaM2YxtMjJlxGyMjI0NjVOrMTAzjU\”, ” +
“\”templateName\”: \”myTemplate.docx\”,” +
“\”outputName\”: \”result\”,” + “\”outputFormat\”: \”PDF\”,” +
“\”data\”:#{JSON_DATA}}”

# Call Cloud with the request and save the response as a file
response = http.request(request)

An API-First Approach

The service was designed knowing that it would primarily be used via the API.

The API has been structured to make it easy to use, whether:

  • Configuring a webhook in a third-party app.
  • Calling the API by writing code.

This makes it possible to use the service from most modern platforms:

  • Custom Software Applications (Java, .Net, PHP, Ruby, Python, etc)
  • Third-Party Apps (CRMs, Webforms, Workflow Automation, etc)
  • Low-Code/No-Code Apps (Appian, Mendix, Bubble, Out Systems, etc)

By default, generated documents are returned to the calling application, allowing the application to perform further actions with the file(s). Other delivery options include:

  • Delivery via email.
  • Stored to an AWS S3 Bucket.
  • Sent using a webhook to third-party services.

The API provides endpoints to perform other tasks, such as: upload, download, list and delete templates; query the structure of a template and return the field names; and check the status of the service and account.

Processing Locations

The cloud advantages of high-availability, increased reliability and scalability, naturally lead to questions about data residency.

processing locations

US Region = https://us.dwsX.docmosis.com/api/xxx

Cloud users can select the physical location used for storing templates/images and choose where processing occurs, via the:

  • Cloud Console – a convenient web portal for uploading templates and testing documents.
  • Document Generation API – the base URL determines the region.

A single Cloud account enables the service to be used in all available regions (United States, Europe and APAC).  Users may choose a region for low-latency/high performance or to satisfy data residency requirements.

 

processing locations

US Region = https://us.dwsX.docmosis.com/api/xxx

docmosis tornado

Cloud is the easiest way to try Docmosis making it perfect for initial evaluation and rapid proof-of-concept work. Teams that prefer a self-hosted solution can also consider Tornado, which provides similar API endpoints, making it easy to move from Cloud to Tornado when ready.

cloud monitoring

Uptime Monitoring

Document production is often mission-critical.

cloud monitoring

Any service must be stable, consistent and always available.

Since 2016 the Cloud service has been monitored 24/7, using the third-party platform Pingdom, by generating a test document every 60 seconds.

View years of publically available historical uptime records. The results show the time taken to complete a deep-test, that activates the rendering engine, and return a single-page document.

System Monitoring

Cloud Versions

The first version of the service was launched in 2011 as Docmosis Web Services (DWS).

processing locations

During the life of any given version all feature additions, environment changes and bug fixes are thoroughly tested to ensure there is 100% consistency in output for all existing users of the service.

Improvements, that can’t be safely applied to the current version, accrue over time and are released as a new version of the service (DWS2, DWS3, DWS4, etc.) that runs in parallel to the previous services.

Cloud Versions Explained
processing locations
cloud account

Getting Started

No credit card, no watermarks, no limitations.

cloud account

Start a free trial and use the service for 30 days, with the option to extend your evaluation if needed. With a trial account you can:

  • Download, upload and manage templates and images
  • Test the generation of documents from within the Cloud Console
  • Create and manage API keys
  • Call the API to generate documents

Follow the instructions on our Resources Website to help you get started. 

Getting Started with Cloud

Security Statement

The service does not store data or generated documents alleviating the majority of security concerns.

Information security is of paramount importance to Docmosis. We continuously develop our security systems and procedures to meet industry best practice.

Key points to note are:

  • The service forces communication over encrypted channels using HTTPS.
  • A best-practice approach is to ensure that templates and images uploaded to the service do not contain Personal Data.
  • All artefacts are stored encrypted at rest.
  • Data and generated documents exist momentarily on the service until either delivery completes or an error occurs, at which point they are immediately and automatically deleted.

Below is a summary of the technical and organisational measures employed by Docmosis in the course of providing the Cloud service.

  1. Physical Security

    1. Processing occurs entirely on Amazon Web Services (AWS) infrastructure. This provides comprehensive physical security and Docmosis takes full advantage of the AWS facilities for supporting non-physical system security.
    2. Docmosis premises has physical access control systems and is protected after hours by an externally monitored security system. The local computer network has multiple layers of network devices to protect against external threats.

  2. Logical Security

    1. Customers access the Services via self-managed passwords (restrictions on minimum length and special characters) with monitoring and notifications to Docmosis of break-in attempts.
    2. API access requires a unique access key that Customers can generate and expire.
    3. Customer actions are audited providing the basis for investigation of incident management.
    4. Docmosis employee access to cloud infrastructure is controlled by two factor authentication.

  3. Security of Data

    1. All communication with the Services must be SSL encrypted.
    2. Templates and other uploaded content and are encrypted at rest.
    3. Personal Data and the generated documents are delivered then automatically and immediately deleted.
    4. Email is dispatched using transport layer security (SMTP TLS).
    5. Processing of data and generated documents is geographically bound within the region selected by the Customer.
    6. Templates and other uploaded content are stored in areas with role-based access and access by Docmosis employees requires interaction with access-control systems.

  1. Availability and Resilience

    1. High Availability Architecture. Load balanced, high-performance, redundant and monitored 24/7.
    2. Docmosis uses publicly visible third-party systems to monitor the availability and performance of Services. Key API end points are monitored every 60 seconds with deep-tests checking the contents of the generated test documents. Historical uptime results can be viewed here: https://www.docmosis.com/monitoring
    3. The service is engineered to survive multiple points of failure, degrade in a predictable manner and remain as operational as possible, even in the event of core systems failures.
    4. Multiple independent backup systems in place providing case-specific recovery options.
    5. Templates and other uploaded content are version controlled and can be reverted and restored on an as-needs basis.
    6. Minor software updates are performed as needed on the service. Status notifications are available here: https://www.docmosis.com/status
    7. Clearly established Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO).

  2. Regular Evaluation and Assessment

    1. Docmosis continually evaluates the security of the Services to determine whether additional or different security measures are required.
    2. Docmosis engages an independent third-party to perform penetration testing of the Services.

  3. Staff Practices

    1. Docmosis employee access to infrastructure and data is limited to that necessary to execute the assigned roles. Data is processed in areas with role-based access.
    2. Docmosis employees are required to read and sign a confidentiality agreement which explains the importance and sensitivity of Personal Data.
    3. Docmosis provides ongoing training to employees on the importance of security and their compliance with the Password Policy and Acceptable Use of IT Policy.