Integration Cesium Automation with Make.com
Connecting Cesium Automation with Make.com, Building Powerful Cross-Platform Workflows
By KorOps Team
Connecting Cesium Automation with Make.com: Building Powerful Cross-Platform Workflows
Modern businesses rarely run on a single application.
Customer data may live in a CRM, documents may be stored in Google Drive, notifications may be sent through Slack or Microsoft Teams, and complex business processes may be handled by a workflow orchestration platform.
The challenge is connecting all of these systems without building and maintaining a custom integration for every combination.
This is where Cesium Automation and Make.com can work particularly well together.
Cesium Automation provides a platform for building and orchestrating API-driven, event-driven, and scheduled workflows, while Make provides a visual way to connect thousands of applications and move data between them.
The result is a useful pattern:
Make handles the integrations. Cesium handles the workflow logic.
In this article, we'll look at how to connect the two and walk through a practical example.
What is Cesium Automation?
Cesium Automation is a workflow orchestration platform designed to automate API-driven, event-driven, and scheduled processes across applications and services.
Instead of writing custom orchestration code, you can define a workflow that describes how a process should execute.
For example, a workflow might:
- Receive customer information.
- Validate the information.
- Call an external API.
- Transform the response.
- Store the result.
- Notify another system.
Cesium becomes particularly useful when the process itself contains meaningful business logic or multiple dependent steps.
What is Make.com?
Make is a visual automation platform that connects applications and services using scenarios and modules.
A Make scenario can contain a sequence of operations such as:
Trigger
↓
Google Sheets
↓
HTTP request
↓
Slack
↓
Email
Make provides thousands of integrations and also provides an HTTP application for connecting services that don't have a dedicated Make integration.
This HTTP capability is the key to integrating Make with Cesium Automation.
How the Cesium–Make Integration Works
The integration does not require Make to have a dedicated Cesium module.
Instead, Make can call a Cesium workflow through its REST API.
Conceptually, the architecture looks like this:
┌─────────────────┐
│ Make.com │
│ │
│ Trigger │
│ ↓ │
│ Prepare data │
│ ↓ │
│ HTTP request │
└────────┬────────┘
│
│ REST API
▼
┌─────────────────┐
│ Cesium │
│ Automation │
│ │
│ Workflow │
│ ↓ │
│ Business logic │
│ ↓ │
│ API calls │
│ ↓ │
│ Transformations │
└────────┬────────┘
│
▼
Workflow result
│
▼
┌─────────────────┐
│ Make.com │
│ │
│ Store / Notify │
│ / Continue │
└─────────────────┘
This separation is useful because each platform can do what it is best at.
Make can act as the integration layer.
Cesium can act as the workflow and orchestration layer.
Step 1: Create a Workflow in Cesium
The first step is to create the workflow that you want Make to execute.
For example, imagine that your company receives a new customer order.
The workflow in Cesium could perform the following operations:
Receive Order
↓
Validate Order
↓
Check Inventory
↓
Calculate Order Value
↓
Create Order Record
↓
Return Result
The workflow can expose inputs that Make will provide when it invokes the workflow.
For example:
{
"customerId": "CUST-10042",
"productId": "PROD-5001",
"quantity": 5
}
The exact input structure will depend on the workflow you create in Cesium.
The important idea is that Make does not need to know how the workflow works internally.
Make simply sends the required inputs.
Cesium takes care of the process.
Step 2: Obtain the Cesium Workflow API Endpoint
Once the workflow is available through the Cesium API, Make can invoke it using an HTTP request.
A typical API request follows this pattern:
POST https://<your-cesium-instance>/cesium/api/v1/workflow/<workflow-id>/execute
The request contains authentication information and the workflow input data.
For example:
Content-Type: application/json
Authorization: Bearer <CESIUM_TOKEN>
The body contains the input parameters required by the workflow.
Step 3: Create a Make Scenario
Now switch to Make.
Create a new scenario and select the application that should trigger the process.
For our example, let's use Google Sheets.
Imagine that your sales team maintains an order sheet:
| Order ID | Customer ID | Product ID | Quantity | | -------- | ----------- | ---------- | -------: | | ORD-1001 | CUST-10042 | PROD-5001 | 5 |
Whenever a new order is added, Make can start the scenario.
The scenario could look like:
Google Sheets
│
│ New order
▼
HTTP
│
│ Call Cesium
▼
Cesium Workflow
│
│ Result
▼
Google Sheets / Slack / Email
Make scenarios are built from modules, and data can be mapped from one module to another.
Step 4: Add the HTTP Module
In Make, add an HTTP module to your scenario.
Configure it to make a POST request to your Cesium workflow endpoint.
For example:
Method:
POST
URL:
https://<your-cesium-instance>/cesium/api/v1/workflow/<workflow-id>/execute
Add the required headers:
Content-Type: application/json
Authorization:
Bearer <your-token>
Make's HTTP integration is specifically intended for connecting services that don't have a native Make integration.
Step 5: Map Make Data into Cesium
This is where the integration becomes powerful.
Instead of hard-coding values in the HTTP request, map values from the previous Make module.
For example, your request body could be:
{
"customerId": "{{Customer ID}}",
"productId": "{{Product ID}}",
"quantity": "{{Quantity}}"
}
The values in {{...}} come from the Google Sheets module.
So if the spreadsheet contains:
Customer ID = CUST-10042
Product ID = PROD-5001
Quantity = 5
Make effectively sends:
{
"customerId": "CUST-10042",
"productId": "PROD-5001",
"quantity": 5
}
This means the same Cesium workflow can process hundreds or thousands of different records without changing the workflow itself.
A Practical Example: Automating Order Processing
Let's make the example slightly more realistic.
Suppose an e-commerce company receives orders through its CRM.
The company wants the following process:
- A new order is created.
- Make detects the new order.
- Make sends the order to Cesium.
- Cesium validates the order.
- Cesium checks the customer's eligibility.
- Cesium calculates the order priority.
- Cesium returns the result.
- Make updates the CRM.
- Make sends a Slack notification to the operations team.
The complete architecture becomes:
┌──────────────┐
│ CRM │
└──────┬───────┘
│
New Order
│
▼
┌──────────────┐
│ Make │
│ │
│ Trigger │
└──────┬───────┘
│
HTTP POST
│
▼
┌──────────────────┐
│ Cesium │
│ │
│ Validate Order │
│ ↓ │
│ Check Customer │
│ ↓ │
│ Calculate │
│ Priority │
└────────┬─────────┘
│
Result
│
▼
┌──────────────┐
│ Make │
└──────┬───────┘
│
┌──────────┴──────────┐
▼ ▼
Update CRM Send Slack
This is much more maintainable than putting all of the business logic directly into Make.
Why Put the Business Logic in Cesium?
At first glance, you might ask:
Why not build everything directly in Make?
That's a reasonable question.
Make is excellent at connecting applications and moving data between them. It provides triggers, actions, mapping, filters, routers, aggregators, and other building blocks for automation.
But there are situations where you may want the workflow itself to live in a dedicated orchestration layer.
For example:
- The workflow is reused by multiple applications.
- The workflow contains complex business logic.
- Multiple systems need to invoke the same process.
- You want your workflow logic separated from your integration logic.
- Your application needs to invoke the workflow programmatically.
- You need API-driven execution.
In these situations, Cesium can become the reusable process layer while Make becomes one of the clients that invokes it.
The Real Power: Reusing the Same Cesium Workflow
Consider the order-processing workflow again.
Today, Make invokes it.
Tomorrow, your website might invoke it.
Your mobile application might invoke it.
A scheduled backend job might invoke it.
Another automation platform could invoke it.
The workflow remains the same.
┌──────────────┐
│ Make │
└──────┬───────┘
│
┌──────▼───────┐
│ │
│ Cesium │
│ Workflow │
│ │
└──────▲───────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Website Mobile App Backend
This is one of the biggest advantages of exposing workflows through an API.
The workflow becomes a reusable service rather than something locked inside one automation platform.
Handling the Response in Make
After Cesium executes the workflow, the HTTP module receives a response.
For example, the workflow might return:
{
"status": "success",
"orderId": "ORD-1001",
"priority": "HIGH",
"approved": true
}
Make can then use these values in subsequent modules.
For example:
Cesium Response
│
├── approved = true
│ ↓
│ Update CRM
│
└── priority = HIGH
↓
Send Slack Alert
Make's mapping capabilities make it possible to take data returned by one module and use it in subsequent modules.
Adding Conditional Logic
The integration becomes even more useful when Make's routing and filtering capabilities are combined with Cesium.
For example:
Cesium
│
Order Result
│
┌────┴────┐
│ │
Approved Rejected
│ │
▼ ▼
CRM Notify
Update Support
A Make router can send the response down different paths.
This allows you to keep responsibilities clear:
Cesium
"What should happen to this order?"
Make
"Where should I send the result?"
That distinction makes complex integrations easier to reason about.
Another Useful Pattern: Scheduled Cesium Workflows
The integration doesn't have to start with an event.
Make can also be used to invoke a Cesium workflow on a schedule.
For example:
Every day at 8:00 AM
↓
Make
↓
HTTP POST
↓
Cesium Workflow
↓
Generate Daily Report
↓
Make
↓
Email / Slack / Google Sheets
This is useful when you have a workflow that needs to run periodically but the output needs to be distributed through multiple business applications.
Make scenarios can be scheduled, while Cesium can handle the actual workflow execution.
Security Considerations
Because the integration uses an API endpoint, authentication is an important part of the setup.
Your Cesium authentication token should never be hard-coded into a document, source repository, or publicly shared scenario configuration.
Instead, keep credentials inside Make's connection or credential configuration where possible.
Make supports authenticated connections and credentials for connecting to external services.
You should also consider:
- Use HTTPS for all API communication.
- Keep tokens out of logs and source code.
- Use the minimum permissions required.
- Rotate credentials periodically.
- Validate inputs inside the Cesium workflow.
- Handle API errors explicitly.
- Avoid sending sensitive data unnecessarily.
Error Handling
A production integration should assume that something will eventually fail.
For example:
Make
│
▼
Cesium API
│
├── 200 → Continue
│
├── 400 → Invalid input
│
├── 401 → Authentication problem
│
├── 404 → Workflow not found
│
└── 500 → Workflow/server error
Make can then route failures into an error-handling path.
For example:
Cesium Error
│
▼
Make Error Handler
│
├── Log error
├── Notify operations
└── Retry if appropriate
This is particularly important for workflows that interact with external APIs.
When Should You Use This Integration?
The Cesium + Make combination is particularly attractive when you have a process that looks something like:
External Event
↓
Make
↓
Complex Business Process
↓
Cesium
↓
Result
↓
Make
↓
Multiple Applications
Good candidates include:
Customer onboarding
A new customer enters your CRM → Make sends the data to Cesium → Cesium performs validation and onboarding logic → Make updates CRM, email, Slack, and other systems.
Order processing
A new order arrives → Make invokes Cesium → Cesium validates and processes the order → Make updates downstream systems.
Data synchronization
A record changes in one application → Make detects it → Cesium performs transformation and business rules → Make updates multiple destination systems.
Reporting
A scheduled Make scenario invokes Cesium → Cesium gathers and processes data → Make distributes the resulting report.
Approval workflows
An approval event occurs → Make sends the request to Cesium → Cesium determines the next steps → Make notifies the relevant people or applications.
The Key Idea
The most useful way to think about the integration is not:
"How do I make Cesium work inside Make?"
Instead, think:
"How can Make act as the integration layer for my Cesium workflows?"
That architectural distinction makes the possibilities much broader.
Make already provides the connectors, triggers, mapping, routing, scheduling, and HTTP capabilities needed to communicate with external services.
Cesium provides the workflow orchestration layer.
Together, they allow you to build an architecture where:
Make connects everything.
Cesium orchestrates the process.
Your applications consume the result.
Conclusion
Integrating Cesium Automation with Make.com doesn't require a complicated custom connector.
The core integration can be built around Cesium's API and Make's HTTP module.
The pattern is straightforward:
1. Build workflow in Cesium
↓
2. Expose the workflow through its API
↓
3. Create a Make scenario
↓
4. Trigger the scenario
↓
5. Make sends data to Cesium
↓
6. Cesium executes the workflow
↓
7. Cesium returns the result
↓
8. Make processes the result
The real value comes from separating integration from orchestration.
Make gives you a visual way to connect your business applications, while Cesium can encapsulate reusable workflow logic behind an API.
Once you establish this pattern, Cesium workflows can become reusable building blocks that can be invoked not only by Make, but by websites, applications, scheduled jobs, and other systems as well.