Node Navigation
Community Activity
Concat values of a field based on value of another field
Hi All, I'm working on a requirement where I need to concatenate the values of field A with '|' based on the value of field B of a JSON array. Below is the example. API response: there're multiple records as below { "impactTimestamp":"2025-10-23T10:47:47ZZ", "la":"1.2", "lg":"3.4", "IR":"12", "IA": [ { "number":"78","type":"C" } { "number":"89","type":"C" } { "number":"123","type":"A" } { "number":"456","type":"A" } ] } desired output: { " impactTimestamp":"2025-10-23T10:47:47ZZ", "la":"1.2", "lg":"3.4", "IR":"12", "impactedAs": "123|456", "impactedCs": "78|89" } I tried multiple ways to filter, map and join functions on the API response but it doesn't work. Group by and Aggregate snaps are asked to be avoided as much so been trying with functions. Please suggest anything either on functions or snaps. Thanks !
Introducing the Agent Snap
7 MIN READ Flashback: What’s an Agent? “Agents are autonomous LLM-based processes that can interact with external systems to carry out a high-level goal.” Agents are LLM-based systems that can perform actions based on the user’s request and the scenario, determined by the LLM of the Agent system. A minimal agent consists of 1. an LLM component, and 2. tools that the Agent can use. Think of the Agent as a Robot with a brain (LLM) + robotic arms (Tools). Based on the request, the brain can “decide” to do something, and then the arm will carry out the action decided by the brain. Then, depending on the scenario, the brain can determine if more action is needed, or end if the request is complete. The process of an agent We previously introduced the “Agent Driver and Agent Worker“ pipeline pattern, which clearly defines every single operation that would occur in an Agent process. The process of the pattern can be described as follows Agent Driver Define the instruction of the Agent. (System prompt) Format the user’s request into a conversation. (Messages array) Define tools to make available to the Agent. Send all information above into a “loop“, run the Agent worker until the process is complete. Agent Worker Call the LLM with the instructions, conversation, and tool definitions LLM decides… If it is able to complete the request, end the conversation and go to step 7. If tool calls are required, go to step 3. Call the tools. Format the tool result. Add the tool results to the conversation Back to step 1. Request is complete, the agent responds. The rationale From the Agent Driver and the Agent Worker pipeline, here’s an observation: The driver pipeline handles all of the “configuration“ of the Agent. The worker pipeline handles the “operation“ of the Agent. Now, imagine this: If we can package the “Agent operation” into a single module, so that we can create Agents just by providing instructions, and tools. Wouldn’t this be great? This is exactly what Agent Snap does. The Agent Snap combines the PipeLoop Snap and the Agent Worker pipeline, so all of the agent operations happen in a single Snap. Information and prerequisites Now, before dreaming about having your own company of agents, since building agents is now so simple, there is some information to know about and conditions to be met before this can happen. 1. Agent Snaps are model-specific The Agent Snap is a combination of the “loop” and the Agent Worker, therefore, the LLM provider to be used for an Agent Snap is also fixed. This design allows users to stick to their favorite combination of customized model parameters. 2. Function(Tool) definitions must be linked to a pipeline to carry out the execution Previously, in an Agent Worker pipeline, the Tool Calling Snap is connected to Pipeline Execute Snaps to carry out tool calls, but this is no longer the case with the Agent Snap. Instead, a function definition should include the path of the pipeline to carry out the execution if this tool is called. This way, we can ensure every tool call can be performed successfully. If the user does not provide a tool pipeline with the function definition, the Agent Snap will not proceed. 3. Expected Input and Output of a tool pipeline When a tool call is requested by an LLM, the LLM will provide the name of the tool to call and the corresponding parameters to call. The Agent Snap will unwrap the parameters and send them directly to the tool pipeline. Here’s an example: I have a tool get_weather, which takes city: string as a parameter. The LLM decides to call the tool get_weather with the following payload: { "name": "get_weather", "parameters": { "city": "New York City" }, "sl_tool_metadata": { ... } } For this to work, my tool pipeline must be able to accept the input document : {"city": "New York City"} On a side note, the sl_tool_metadata object will also be available to the tool pipeline as the input for APIM and OpenAPI tools. Now, assume my tool pipeline has successfully retrieved the weather of New York City, It’s time for the Agent Snap to collect the result of this tool call. The Agent Snap will collect everything from the output document of the tool pipeline as the tool call result*. So that the LLM can determine the next steps properly. *Note: with one exception, if the output of a “tool pipeline“ contains the field “messages“ or "contents", it will be treated as the conversational history of the “child agent”, which will be filtered and will not be included. Build an Agent with Agent Snap We’ve understood the idea, we’ve gone through the prerequisites, and it’s time to build an Agent. In this example, we have an Agent with 2 tools: a weather tool and a calendar tool. We first start with a prompt generator to format the user input. Then define the tools the Agent can access. Let’s look into one of the tool definitions. In this example tool, we can see the name of the tool, the description of the tool, the parameters, and the path of the tool pipeline to carry out this task. This satisfies the requirement of a tool to be used by an Agent Snap. After we have the tools set, let’s look at the Agent Snap, using the Amazon Bedrock Converse API Agent Snap as an example. The configuration of an Agent Snap is similar to its corresponding Tool calling Snap, except for some extra fields, such as a button to visualize the agent flow, and a section to configure the operation of the Agent, such as iteration limit and number of threads for tool pipeline executions. The Agent Snap handles the whole executional process, and terminates when 1. The request is complete (no more tool calls are required) or 2. An error occurred. Voila! You have created an agent. After the Agent pipeline completes a round of execution, the user can use the “Visualize Agent Flow“ button in the Agent Snap to see the tools that are called by the LLM. Tips and Tricks for the Agent Snap Let’s take a look at the features built into the Agent Snap. Reuse pipelines Most agentic tool calls are processes that can be reused. To minimize execution load, we can use the “Reuse tool pipeline“ feature. This feature allows tool pipeline instances to be reused, so that the Agent will not need to spawn a pipeline every time a tool is called. To use this feature, the tool pipeline to be reused must be “Ultra compatible“; otherwise, the pipeline execution would hang, and the Agent Snap would eventually timeout. Tool call monitoring Agents can be long-running; it’s not rare to have an Agent run multiple iterations. To see what’s happening in the process, Agent Snap has built in monitoring during validation. The user will be able to see the iteration index, the tool that is currently being called, and the parameters that are used for the tool call in the pipeline statistics status bar. Selecting the “Monitor tool call“ option includes the parameter in the status update, which is an opt-in feature. If the user does not wish to expose the information to SnapLogic, the user should disable this. Warnings Agent configuration is a delicate process; a mistake can potentially lead to errors. The Agent Snap has a bunch of built-in warning capabilities, so the user can be better aware of what could go wrong. 1. Agent process completed before all tool calls completed In the Agent Snap, there is an Iteration limit setting, which limits the number of iterations the Agent can run. If the user provided a smaller limit, which caused the Agent to stop while the LLM is still awaiting tool calls, this warning would pop up to signal the user that the execution is incomplete. 2. Tool pipeline path is not defined A function (tool) definition to be used by the Agent Snap should include a tool pipeline path, so the Agent Snap can link to the actual pipeline that carries out the execution. If the pipeline path is not included in the function definition, this warning will pop up to signal the user that the Agent will not proceed. 3. Duplicate tool naming As we try to add more and more tools to the Agent Snap, two tools likely share the same name. The Agent Snap has the ability to rename the tools being sent to the LLM, and then still link to the correct pipeline. There will also be a warning available in the pipeline statistics to alert the user about a change in the behavior. Release Timeframes The Agent Snap is the foundation of the next-generation SnapLogic Agent. We will be releasing 4 Agent Snaps in the November release: Amazon Bedrock Converse API Agent OpenAI Chat Completions Agent Azure OpenAI Chat Completions Agent Google Gemini API Agent To better use the Agent Snaps, we will be introducing new capabilities to some of our Function Generators as well. Here is the list of Function Generator Snaps that will be modified soon: APIM Function Generator Snap OpenAPI Function Generator Snap MCP Function Generator Snap We hope you are as excited as we are about this one.
trace API and proxy calls
Hi ! I'm new to Snaplogic and I would like to trace all API and proxy calls in Datadog. Is there a way in SnapLogic to access a list that contains all API and proxy calls that have been made, along with their response codes? Additionally, in order to create a dashboard in Datadog, where can I find the necessary information in SnapLogic to retrieve this data? Thank you for the help !
JWT Configuration for SnapLogic Public API
This document details the process of configuring JWT authentication for the SnapLogic Public API using self-generated keys without the use of any third party JWT providers. It covers key generation, JWKS creation, SnapLogic configuration. 1. Key Generation and JWKS Creation 1.1 Setup the CMD Open CMD Mount the OpenSSL bin folder 1.2 Generate the Private Key Use the following command to generate a 2048-bit RSA private key in the PEM format. BASH openssl genpkey -algorithm RSA -out jwt_private_key.pem -pkeyopt rsa_keygen_bits:2048 Result:A file named jwt_private_key.pem will be created. This key must be kept secret and secure. 1.3 Convert to PKCS#8 Format The JWT generation requires the private key to be in the PKCS#8 format for proper decoding. So, convert the jwt_private_key.pem into PKCS8 format. BASH openssl pkcs8 -topk8 -in jwt_private_key.pem -out jwt_private_key_pkcs8.pem -nocrypt Result:A new file, jwt_private_key_pkcs8.pem, will be created. Use this key in your application for signing JWTs. 1.4 Extract the Public Key The public key is required for the JWKS document. BASH openssl rsa -in jwt_private_key_pkcs8.pem -pubout -out jwt_public_key_pkcs8.pem Result:A file named jwt_public_key.pem will be created. 1.5 Extract Public Key Components for JWKS: Extract the Modulus and Exponent from the CA-signed public key. These are the core components of your JWKS. BASH openssl rsa -pubin -in jwt_public_key_pkcs8.pem -text -noout The output will look like this:Public-Key: (2048 bit)Modulus: 00:d2:e3:23:2c:15:a6:5b:54:c1:89:f7:5f:41:bf:...Exponent: 65537 (0x10001) 2. JWKS Creation and JWT Endpoint Configuration 2.1. The below steps explain how to create the JWKS JSON within Snaplogic. 2.1.1 Create a new project sapce and a project "JWKS" or even an API with name "JWKS" - (This step is just for access control and the API policy to be applied only for this purpose) 2.1.2 Create the pipeline CreateJWKS 2.1.3 Update the Modulus and Exponent values in the mapper copied from the step 1.5 in the section Key Generation, JWKS Creation, and Certificate Signing. 2.1.4 Select the language as Python and replace the default script in the script snap with # Import the interface required by the Script snap. from com.snaplogic.scripting.language import ScriptHook import base64 import hashlib class TransformScript(ScriptHook): def __init__(self, input, output, error, log): self.input = input self.output = output self.error = error self.log = log # Helper function to convert an integer to a big-endian byte string # This is a manual implementation of int.to_bytes() for Python 2.7 def int_to_bytes(self, n): if n == 0: return '\x00' hex_string = "%x" % n if len(hex_string) % 2 == 1: hex_string = '0' + hex_string return hex_string.decode("hex") def execute(self): self.log.info("Executing Transform script") while self.input.hasNext(): try: inDoc = self.input.next() # Modulus conversion logic hex_input = inDoc['hex_string_field'] clean_hex_string = hex_input.replace('\n', '').replace(' ', '').replace(':', '') modulus_bytes = clean_hex_string.decode("hex") modulus_base64url = base64.urlsafe_b64encode(modulus_bytes).rstrip('=') # Exponent conversion logic exponent_input_str = inDoc['exponent_field'] import re match = re.search(r'^\d+', exponent_input_str) if match: exponent_int = int(match.group(0)) else: raise ValueError("Could not parse exponent value from string.") exponent_bytes = self.int_to_bytes(exponent_int) exponent_base64url = base64.urlsafe_b64encode(exponent_bytes).rstrip('=') # Dynamic Key ID (kid) generation logic # Concatenate the Base64url-encoded modulus and exponent jwk_string = modulus_base64url + exponent_base64url # Compute the SHA-256 hash kid_hash = hashlib.sha256(jwk_string).digest() # Base64url encode the hash to create the kid kid = base64.urlsafe_b64encode(kid_hash).rstrip('=') # Prepare the output document with all values outDoc = { 'modulus_base64url': modulus_base64url, 'exponent_base64url': exponent_base64url, 'kid': kid } self.output.write(inDoc, outDoc) except Exception as e: errDoc = { 'error' : str(e) } self.log.error("Error in python script: " + str(e)) self.error.write(errDoc) self.log.info("Script executed") def cleanup(self): self.log.info("Cleaning up") hook = TransformScript(input, output, error, log) 2.1.5 Replace the default value in the JSON generator with { "keys": [ { "kty": "RSA", "alg": "RS256", "kid": $kid, "use": "sig", "e": $exponent_base64url, "n": $modulus_base64url } ] } This will return us the JWKS JSON. 2.2. The below step creates the public endpoint for the JWKS JSON. The below steps can be done as a standalone API as well as a separate project for this JWKS authentication. 2.2.1 Create the pipeline getJWKS 2.2.2 Paste the JWKS generated in step 2.1.5 above in the JSON Generator: { "keys": [ { "kty": "RSA", "alg": "RS256", "kid": "vTfx70NbtVbarHnBetDHNqLXsWVr4Ue5oC32TFNSMlc", "use": "sig", "e": "AQAB", "n": "ANLjIywVpltUwYn3X0G_********_3JmpnSh419wDZC_8-Ts" } ] } 2.2.3 Follow the config as shown for JSON Formatter: 2.2.4 Create a Task named jwks.json and follow the task config as shown and copy the Ultra Task HTTP Endpoint: Select the Snaplex as Cloud, as the endpoint have to be truly public. 2.2.5 Create an API Policy - Anonymous Authenticator and key in the details as shown: 2.2.6 Create an API Policy - Authorize By Role and key in the details as shown: 3. SnapLogic JWT Configuration This step links SnapLogic to your JWKS. Configure Admin Manager: 3.1 In the SnapLogic Admin Manager, navigate to Authentication > JWT. 3.1.1 Issuer ID: Enter a unique identifier for your issuer. This can be a custom string. 3.1.2 JWKS Endpoint: Enter the full HTTPS URL where you have hosted the JWKS JSON file, HTTP Endpoint copied from step B.4 in the Section JWKS Creation and JWT Endpoint Configuration. 3.2 In the SnapLogic Admin Manager, navigate to Allowlists > CORS allowlist 3.2.1 Add domain: Key in the domain https://*.snaplogic.com in the Domain text box, click on Add Domain and click on Save. 4. JWT Generation and Structure The JWT must be created with a header that references your custom kid and a payload with claims that match SnapLogic's requirements. 4.1 Header: JSON { "alg": "RS256", "typ": "JWT", "kid": "use the key id generated in step 2.1.5 from the section JWKS Creation and JWT Endpoint Configuration"} 4.2 Payload: JSON { "iat": {{timestampIAT}}, "exp": {{timestampEXP}}, "sub": "youremail@yourcompany.com", "aud": "https://elastic.snaplogic.com/api/1/rest/public", "iss": "issuer id given in section 3.1.1.1", "org": "Your Snaplogic Org" } 4.3 Sign the JWT: Use the jwt_private_key_pkcs8.pem to sign the token with your application's JWT library. 4.4 Postman Pre-Request script to automatically generate epoch timestamps for iat and exp claims let now = new Date().getTime(); let iat = (now/1000) let futureTime = now + (3600 * 1000); let exp = (futureTime/1000) // Set the collection variable pm.collectionVariables.set("timestampIAT", iat); pm.collectionVariables.set("timestampEXP", exp);
Welcome to the Gold Star to the Winner Challenge - Halloween 2025 Edition! ⭐️
From time to time I send out to my team at SnapLogic fun pipeline building challenges that Expression Enthusiasts may enjoy solving. We have decided to open it up to the broader Snaplogic Community. The Gold Star to the Winner Challenge Halloween 2025 Edition is the spookiest challenge of the year. Your job will be to cast a powerful spell in the form of an expression to tame some monstrously messy data. As usual, this challenge is from a real world use case. It centers on schemalessly transforming ‘somewhat’ structured data into a perfectly structured, “OCD-approved” format. The Details: In the following dataset, there are two keys: “Name” and “Path”. The Trick is to craft an expression that can magically break apart the Path string into separate keys, numbering them sequentially (pathelement_1, pathelement_2, etc.).For example: a path with 3 elements in it would transform to 3 json keys:Input JSON: { “Path”:“my drive/matt/customers” } Output JSON: { “pathelement_1: “my drive”, “pathelement_2": “matt”, “pathelement_3": “customers” } Here’s the raw input to be put in a JSON Generator: [{"Name":"Fred","Path":"spooky/graveyard/tombstones/fog/cackles/witches/brewing/potions/spells/hauntedhouse.jpg"},{"Name":"Wilma","Path":"kids/yard ornaments/ghosts/goblins/monsters/jack o lantern/leaves/cocoa/chill/candysacks/excitement/pumpkins/tricks/treats.png"},{"Name":"Pebbles","Path":"shadows/bats/moonlight/screams/night/costumes/party.mp4"},{"Name":"Dino","Path":"creepy/cornfields/scarecrows/spiders/webs.gif"}] And the expected output: [{"pathelement_1":"spooky","pathelement_2":"graveyard","pathelement_3":"tombstones","pathelement_4":"fog","pathelement_5":"cackles","pathelement_6":"witches","pathelement_7":"brewing","pathelement_8":"potions","pathelement_9":"spells","pathelement_10":"hauntedhouse.jpg","Name":"Fred"},{"pathelement_1":"kids","pathelement_2":"yard ornaments","pathelement_3":"ghosts","pathelement_4":"goblins","pathelement_5":"monsters","pathelement_6":"jack o lantern","pathelement_7":"leaves","pathelement_8":"cocoa","pathelement_9":"chill","pathelement_10":"candysacks","pathelement_11":"excitement","pathelement_12":"pumpkins","pathelement_13":"tricks","pathelement_14":"treats.png","Name":"Wilma"},{"pathelement_1":"shadows","pathelement_2":"bats","pathelement_3":"moonlight","pathelement_4":"screams","pathelement_5":"night","pathelement_6":"costumes","pathelement_7":"party.mp4","Name":"Pebbles"},{"pathelement_1":"creepy","pathelement_2":"cornfields","pathelement_3":"scarecrows","pathelement_4":"spiders","pathelement_5":"webs.gif","Name":"Dino"}] Solution approaches: There are many ways to skin this cat; highlighting the flexibility of the SnapLogic platform. My solution contains a single expression in a mapper. Others (the purists) have solved this by configuring and connecting many transform Snaps. All solutions are good as long as the solutions matches the above expected output and is done in a completely schemaless way. The Prize: The winner will receive recognition in the form of SnapLogic Swag (👕🥤🍾 🎁...). The rules: To keep the playing field level, send solutions directly to me via email (msager@snaplogic.com) and attach your pipeline .slp file. (i.e. we don't want to give solutions out on this post for others to see) Contest ends on 10/31/2025 Good Luck to All! I look forward to seeing your solutions.
SnapLogic Test Automation with Robot Framework: A Complete Testing Solution
7 MIN READ Introduction In today's fast-paced integration landscape, ensuring the reliability and performance of your SnapLogic pipelines is crucial. We're excited to introduce a comprehensive test automation framework that combines the power of Robot Framework with SnapLogic's APIs to deliver a robust, scalable, and easy-to-use testing solution. This approach leverages the snaplogic-common-robot [PyPI-published library] to provide prebuilt Robot Framework keywords for interacting with SnapLogic Public APIs, integrated within a Docker-based environment.. This lets teams spin up full SnapLogic environments on demand—including Groundplex, databases, and messaging services—so tests run the same way everywhere This blog post explores two key components of our testing ecosystem: snaplogic-common-robot: A PyPI-published library https://pypi.org/project/snaplogic-common-robot/ providing reusable Robot Framework keywords for SnapLogic automation snaplogic-robotframework-examples: A public repository providing a complete testing framework with baseline test suites and Docker-based infrastructure for comprehensive end-to-end pipeline validation Key Features and Benefits 1. Template-Based Testing The framework supports template-driven test cases, allowing you to: Define reusable test patterns Parameterize test execution Maintain consistency across similar test scenarios 2. Intelligent Environment Management The framework automatically: Loads environment variables from multiple .env files Auto-detects JSON values and converts them to appropriate Robot Framework variables Validates required environment variables before test execution Why Robot Framework for SnapLogic Testing? Robot Framework offers several advantages for SnapLogic test automation: Human-readable syntax: Tests are written in plain English, making them accessible to both technical and non-technical team members Keyword-driven approach: Promotes reusability and reduces code duplication Extensive ecosystem: Integrates seamlessly with databases, APIs, and various testing tools Comprehensive reporting: Built-in HTML reports with detailed execution logs CI/CD friendly: Easy integration with Jenkins, GitLab CI, and other automation platforms The Power of Docker-Based Testing Infrastructure One of the most powerful features of our framework is its Docker-based architecture. Isolated Test Environments: Each test run operates in its own containerized environment Groundplex Control: Automatically spin up and tear down Groundplex instances for testing Database Services: Pre-configured containers for Oracle, PostgreSQL, MySQL, SQL Server, DB2, and more Message Queue Systems: Integrated support for Kafka, ActiveMQ, and other messaging platforms Storage Services: MinIO for S3-compatible object storage testing This architecture allows below capabilities: Test in production-like environments without affecting actual production systems Quickly provision and tear down complete testing stacks Run parallel tests with isolated resources Ensure consistency across different testing environments snaplogic-common-robot Library Installation The snaplogic-common-robot library is published on PyPI, making installation straightforward https://pypi.org/project/snaplogic-common-robot/ pip install snaplogic-common-robot Core Components The library provides the below components SnapLogic APIs: Low-level keywords for direct API interactions SnapLogic Keywords: High-level business-oriented keywords for common operations Common Utilities: Database connections, file operations, and utility functions. Dependency Libraries: Install all necessary dependency libraries to run Robot Framework tests for SnapLogic. These libraries support API testing, database operations, Docker container testing, JMS messaging, and AWS integration tools. The following libraries are automatically installed as dependencies when you install snaplogic-common-robot, providing comprehensive API support. This library ecosystem continues to expand as we add support for additional features and capabilities. Snaplogic RobotFramework-examples Repository The snaplogic-robotframework-examples repository demonstrates how to build a complete testing framework using the snaplogic common library.https://github.com/SnapLogic/snaplogic-robotframework-examples Framework Overview Note: This project structure is continuously evolving! We're actively working to make the framework easier and more efficient to use,The structure is subject to change as we iterate on improvements to enhance developer experience and framework efficiency. The framework follows a modular architecture with clear separation of concerns: Configuration Layer .env and .env.example manage environment variables for sensitive credentials and URLs env_files/ folder have all details required for creating accounts Makefile provides a central command interface for all build and test operations docker-compose.yml orchestrates the entire multi-container environment with a single command Build Automation makefiles/ directory contains modular scripts organized by service type (databases, messaging, mocks) Each service category has dedicated makefiles for independent lifecycle management Infrastructure docker/ holds Docker configurations for all services (Groundplex, Oracle, PostgreSQL, Kafka) env_files/ stores service-specific environment variables to isolate configuration Containerized approach ensures reproducible test environments across all systems Test Organization test/suite/ contains Robot Framework test suites organized by pipeline functionality test/test_data/ provides input files and expected outputs for validation Tests are grouped logically (Oracle, PostgreSQL+S3, Kafka) for easy maintenance Pipeline Assets src/pipelines/ stores the actual SnapLogic SLP files being tested src/tools/ includes helper utilities and requirements.txt with Python dependencies The snaplogic-common-robot library is installed via requirements.txt, providing reusable keywords Test Reporting Robot Framework automatically generates comprehensive test reports after each execution report.html provides a high-level summary with pass/fail statistics and execution timeline log.html offers detailed step-by-step execution logs with keyword-level information output.xml contains structured test results in XML format for CI/CD integration Reports include screenshots, error messages, and detailed traceability for debugging All reports are timestamped and can be archived for historical analysis Supporting Components travis_scripts/ enables CI/CD automation for continuous testing README/ holds project documentation and setup guides Key Architecture Benefits Modular design allows independent service management Docker isolation ensures consistent test environments Makefile automation simplifies complex operations Clear directory structure improves maintainability CI/CD integration enables automated testing workflows Integration with CI/CD Pipelines One of the most powerful aspects of our Robot Framework testing solution is its seamless integration with CI/CD pipelines. This enables continuous testing, ensuring that every code change is automatically validated against your SnapLogic integrations. Why CI/CD Integration Matters In modern DevOps practices, manual testing becomes a bottleneck. By integrating our Robot Framework tests into your CI/CD pipeline, you achieve: Automatic Test Execution: Tests run automatically on every commit, pull request, or scheduled interval Early Bug Detection: Issues are caught immediately, not days or weeks later in production Consistent Testing: The same tests run every time, eliminating human error and variability Fast Feedback Loop: Developers know within minutes if their changes broke existing integrations Quality Gates: Prevent deployments if tests fail, ensuring only validated code reaches production Jenkins is one of the most popular CI/CD tools, and integrating our Robot Framework tests is straightforward. How It Works? Stage 1: Prepare Environment Install SnapLogic common Robot library and required dependencies Stage 2: Start Docker Services Launches Groundplex, Oracle DB, Kafka, and MinIO containers Stage 3: Run Robot Framework Tests Execute test suites in parallel across 4 threads using pabot Stage 4: Publish Test Results Generate HTML reports, XML results, and test artifacts and can upload to S3. Stage 5: Send Notifications Distributes test results via Slack. Post: Cleanup Tears down containers, removes temp files, archives logs Slack Notifications include the below details Our CI/CD pipeline automatically sends detailed test execution reports to Slack, providing immediate visibility into test results for the entire team. HTML Reports have the below details Robot Framework automatically generates comprehensive HTML reports after each test execution, providing detailed insights into test results, performance, and execution patterns. Real-World Benefits Here's what this means for your team: For Developers Push code with confidence - Tests run automatically Get feedback in minutes - No waiting for QA cycles Fix issues immediately - While the code is still fresh in your mind For QA Teams Focus on exploratory testing - Let automation handle regression Better test coverage - Tests run on every single change Clear reports - See exactly what's tested and what's not Future Enhancements We're continuously improving the framework with planned features include: Enhanced support for more end points Integration with cloud storage services Advanced performance testing capabilities Enhanced security testing features Conclusion The combination of snaplogic-common-robot library and snaplogic-robotframework-examples framework provides a powerful, scalable solution for SnapLogic test automation. By leveraging Docker's containerization capabilities, Robot Framework's simplicity, and SnapLogic's robust APIs, teams can: Reduce testing time from hours to minutes Increase test coverage with automated end-to-end scenarios Improve reliability through consistent, repeatable tests Enable continuous testing in CI/CD pipelines Whether you're testing simple pipeline transformations or complex multi-system integrations, this framework provides the tools and patterns needed for comprehensive SnapLogic testing. Getting Involved We welcome contributions from the SnapLogic community! Here's how you can get involved: Try the Framework: Install snaplogic-common-robot and run the example tests Report Issues: Help us improve by reporting bugs or suggesting enhancements Contribute Code: Submit pull requests with new keywords or test patterns Share Your Experience: Let us know how you're using the framework in your organization Resources snaplogic-common-robot on PyPI: pip install snaplogic-common-robot https://pypi.org/project/snaplogic-common-robot/ snaplogic-robotframework-example repo: https://github.com/SnapLogic/snaplogic-robotframework-examples Documentation: Comprehensive HTML documentation available after installation via README folder Community Support: Join the discussion in SnapLogic Community forums Start automating your SnapLogic tests today and experience the power of comprehensive, containerized test automation! Questions? We're Here to Help! We hope this comprehensive guide helps you get started with automated testing for your SnapLogic integrations. The combination of snaplogic-common-robot and Docker-based infrastructure provides a powerful foundation for building reliable, scalable test automation. Have questions or need assistance implementing this framework? The SLIM (SnapLogic Intelligent Modernization) team is here to support you! We'd love to hear about your use cases, help you overcome any challenges, or discuss how this framework can be customized for your specific needs. Contact the SLIM Team: Reach out to us directly through the SnapLogic Community forums Tag us in your questions with @slim-team Email us at: slim-team@snaplogic.com We're committed to helping you achieve testing excellence and look forward to seeing how you leverage this framework to enhance your SnapLogic automation journey! Happy Testing! The SLIM TeamSnapLogic Product Release - October 2025
This week we released the SnapLogic October 2025 Release. This update brings key enhancements across AI, automation, and observability—plus an important change to how you monitor your pipelines. Dashboard Retirement & New Monitor Training As of this release, the legacy Dashboard has been officially retired. All execution, health, and observability functions are now available in Monitor, which is your primary and default app going forward. To help people get started, a new on-demand training video is available that walks through the Monitor layout, key features, and customization options. Just follow the link here to watch: Monitor Overview & Training Video. You can already read more about SnapLogic Monitor by checking out the Monitor community post October 2025 Release Highlights AgentCreator Introduced LLM-agnostic Function Generator Snaps for building reusable agent functions across OpenAI, Azure OpenAI, Google GenAI, and Amazon Bedrock Added GPT-5 and Claude 4 model support Prompt Composer now features adjustable panels for a more flexible workspace. AutoSync Added Google Service Account JSON authentication for BigQuery endpoints. Enhanced error visibility and reliability for integrations that previously stalled in “running” state. Snaps PostgreSQL Multi Execute Snap for multiple write operations in one transaction. In-memory OAuth2 Accounts improve HTTP Client Snap performance. AWS Signature V4 and Redshift Snaps enhanced for IAM and cross-account access. Monitor The new destination for monitoring and metrics. New usability improvements: Search within filters Scrollable execution tables Status icons now include descriptive text for clarity Platform and Snaplex Update We recommend upgrading to Snaplex version main-36396 - 4.42.2.0 to benefit from performance fixes and enhanced reliability in Triggered Tasks and Snaplex node logging. For full release details, visit the October 2025 Release NotesSnapLogic Monitor: Official Training Module
As previously announced, we will be officially sunsetting Classic Dashboard and transitioning to Monitor as the exclusive monitoring experience with the Snaplogic October 8, 2025, release. To help with this transition, we're excited to launch a detailed, in-depth training course focused exclusively on Monitor. This comprehensive, self-paced course is designed to provide your team with the expertise to master Monitor at your own pace. The curriculum delivers in-depth coverage on all aspects of Monitor, including monitoring and troubleshooting pipeline executions, observing node and snaplex infrastructure health metrics, activity logging, asset catalog and insights. Integrated knowledge checks are included to reinforce key concepts, ensuring you can confidently leverage the full power of the new experience. We strongly encourage you and your teams to take advantage of this new training. SnapLogic is here to accelerate your Monitor journey and this course will be free of charge for the next 6 months. You can access this training by clicking on the link below or by copying and pasting in your browser: https://learn.snaplogic.com/snaplogic-monitor In addition to the above, we also have the below resources to help with this transition: Monitor Tutorial Youtube Videos Monitor Migration Guide Monitor FAQ If you have any technical challenges or questions about the course, please contact your customer success manager or Snaplogic customer support at support@snaplogic.com.
Recent Blogs
7 MIN READ
Flashback: What’s an Agent?
“Agents are autonomous LLM-based processes that can interact with external systems to carry out a high-level goal.”
Agents are LLM-based systems that can perform actions based on the user’s request and the scenario, determined by the LLM of the Agent system. A minimal agent consists of 1. an LLM component, and 2. tools that the Agent can use. Think of the Agent as a Robot with a brain (LLM) + robotic arms (Tools). Based on the request, the brain can “decide” to do something, and then the arm will carry out the action decided by the brain. Then, depending on the scenario, the brain can determine if more action is needed, or end if the request is complete.
The process of an agent
We previously introduced the “Agent Driver and Agent Worker“ pipeline pattern, which clearly defines every single operation that would occur in an Agent process. The process of the pattern can be described as follows
Agent Driver
Define the instruction of the Agent. (System prompt)
Format the user’s request into a conversation. (Messages array)
Define tools to make available to the Agent.
Send all information above into a “loop“, run the Agent worker until the process is complete.
Agent Worker
Call the LLM with the instructions, conversation, and tool definitions
LLM decides…
If it is able to complete the request, end the conversation and go to step 7.
If tool calls are required, go to step 3.
Call the tools.
Format the tool result.
Add the tool results to the conversation
Back to step 1.
Request is complete, the agent responds.
The rationale
From the Agent Driver and the Agent Worker pipeline, here’s an observation:
The driver pipeline handles all of the “configuration“ of the Agent.
The worker pipeline handles the “operation“ of the Agent.
Now, imagine this:
If we can package the “Agent operation” into a single module, so that we can create Agents just by providing instructions, and tools. Wouldn’t this be great?
This is exactly what Agent Snap does. The Agent Snap combines the PipeLoop Snap and the Agent Worker pipeline, so all of the agent operations happen in a single Snap.
Information and prerequisites
Now, before dreaming about having your own company of agents, since building agents is now so simple, there is some information to know about and conditions to be met before this can happen.
1. Agent Snaps are model-specific
The Agent Snap is a combination of the “loop” and the Agent Worker, therefore, the LLM provider to be used for an Agent Snap is also fixed. This design allows users to stick to their favorite combination of customized model parameters.
2. Function(Tool) definitions must be linked to a pipeline to carry out the execution
Previously, in an Agent Worker pipeline, the Tool Calling Snap is connected to Pipeline Execute Snaps to carry out tool calls, but this is no longer the case with the Agent Snap. Instead, a function definition should include the path of the pipeline to carry out the execution if this tool is called. This way, we can ensure every tool call can be performed successfully. If the user does not provide a tool pipeline with the function definition, the Agent Snap will not proceed.
3. Expected Input and Output of a tool pipeline
When a tool call is requested by an LLM, the LLM will provide the name of the tool to call and the corresponding parameters to call. The Agent Snap will unwrap the parameters and send them directly to the tool pipeline.
Here’s an example: I have a tool get_weather, which takes city: string as a parameter. The LLM decides to call the tool get_weather with the following payload:
{ "name": "get_weather", "parameters": { "city": "New York City" }, "sl_tool_metadata": { ... } }
For this to work, my tool pipeline must be able to accept the input document :
{"city": "New York City"}
On a side note, the sl_tool_metadata object will also be available to the tool pipeline as the input for APIM and OpenAPI tools.
Now, assume my tool pipeline has successfully retrieved the weather of New York City, It’s time for the Agent Snap to collect the result of this tool call. The Agent Snap will collect everything from the output document of the tool pipeline as the tool call result*. So that the LLM can determine the next steps properly.
*Note: with one exception, if the output of a “tool pipeline“ contains the field “messages“ or "contents", it will be treated as the conversational history of the “child agent”, which will be filtered and will not be included.
Build an Agent with Agent Snap
We’ve understood the idea, we’ve gone through the prerequisites, and it’s time to build an Agent.
In this example, we have an Agent with 2 tools: a weather tool and a calendar tool. We first start with a prompt generator to format the user input. Then define the tools the Agent can access.
Let’s look into one of the tool definitions.
In this example tool, we can see the name of the tool, the description of the tool, the parameters, and the path of the tool pipeline to carry out this task. This satisfies the requirement of a tool to be used by an Agent Snap.
After we have the tools set, let’s look at the Agent Snap, using the Amazon Bedrock Converse API Agent Snap as an example.
The configuration of an Agent Snap is similar to its corresponding Tool calling Snap, except for some extra fields, such as a button to visualize the agent flow, and a section to configure the operation of the Agent, such as iteration limit and number of threads for tool pipeline executions.
The Agent Snap handles the whole executional process, and terminates when 1. The request is complete (no more tool calls are required) or 2. An error occurred.
Voila! You have created an agent.
After the Agent pipeline completes a round of execution, the user can use the “Visualize Agent Flow“ button in the Agent Snap to see the tools that are called by the LLM.
Tips and Tricks for the Agent Snap
Let’s take a look at the features built into the Agent Snap.
Reuse pipelines
Most agentic tool calls are processes that can be reused. To minimize execution load, we can use the “Reuse tool pipeline“ feature. This feature allows tool pipeline instances to be reused, so that the Agent will not need to spawn a pipeline every time a tool is called.
To use this feature, the tool pipeline to be reused must be “Ultra compatible“; otherwise, the pipeline execution would hang, and the Agent Snap would eventually timeout.
Tool call monitoring
Agents can be long-running; it’s not rare to have an Agent run multiple iterations. To see what’s happening in the process, Agent Snap has built in monitoring during validation. The user will be able to see the iteration index, the tool that is currently being called, and the parameters that are used for the tool call in the pipeline statistics status bar.
Selecting the “Monitor tool call“ option includes the parameter in the status update, which is an opt-in feature. If the user does not wish to expose the information to SnapLogic, the user should disable this.
Warnings
Agent configuration is a delicate process; a mistake can potentially lead to errors. The Agent Snap has a bunch of built-in warning capabilities, so the user can be better aware of what could go wrong.
1. Agent process completed before all tool calls completed
In the Agent Snap, there is an Iteration limit setting, which limits the number of iterations the Agent can run. If the user provided a smaller limit, which caused the Agent to stop while the LLM is still awaiting tool calls, this warning would pop up to signal the user that the execution is incomplete.
2. Tool pipeline path is not defined
A function (tool) definition to be used by the Agent Snap should include a tool pipeline path, so the Agent Snap can link to the actual pipeline that carries out the execution. If the pipeline path is not included in the function definition, this warning will pop up to signal the user that the Agent will not proceed.
3. Duplicate tool naming
As we try to add more and more tools to the Agent Snap, two tools likely share the same name. The Agent Snap has the ability to rename the tools being sent to the LLM, and then still link to the correct pipeline. There will also be a warning available in the pipeline statistics to alert the user about a change in the behavior.
Release Timeframes
The Agent Snap is the foundation of the next-generation SnapLogic Agent. We will be releasing 4 Agent Snaps in the November release:
Amazon Bedrock Converse API Agent
OpenAI Chat Completions Agent
Azure OpenAI Chat Completions Agent
Google Gemini API Agent
To better use the Agent Snaps, we will be introducing new capabilities to some of our Function Generators as well. Here is the list of Function Generator Snaps that will be modified soon:
APIM Function Generator Snap
OpenAPI Function Generator Snap
MCP Function Generator Snap
We hope you are as excited as we are about this one.
2 days ago
Introduction
In today's fast-paced integration landscape, ensuring the reliability and performance of your SnapLogic pipelines is crucial. We're excited to introduce a comprehensive test automation framework that combines the power of Robot Framework with SnapLogic's APIs to deliver a robust, scalable, and easy-to-use testing solution.
This approach leverages the snaplogic-common-robot [PyPI-published library] to provide prebuilt Robot Framework keywords for interacting with SnapLogic Public APIs, integrated within a Docker-based environment..
This lets teams spin up full SnapLogic environments on demand—including Groundplex, databases, and messaging services—so tests run the same way everywhere
This blog post explores two key components of our testing ecosystem:
snaplogic-common-robot: A PyPI-published library https://pypi.org/project/snaplogic-common-robot/ providing reusable Robot Framework keywords for SnapLogic automation
snaplogic-robotframework-examples: A public repository providing a complete testing framework with baseline test suites and Docker-based infrastructure for comprehensive end-to-end pipeline validation
Key Features and Benefits
1. Template-Based Testing
The framework supports template-driven test cases, allowing you to:
Define reusable test patterns
Parameterize test execution
Maintain consistency across similar test scenarios
2. Intelligent Environment Management
The framework automatically:
Loads environment variables from multiple .env files
Auto-detects JSON values and converts them to appropriate Robot Framework variables
Validates required environment variables before test execution
Why Robot Framework for SnapLogic Testing?
Robot Framework offers several advantages for SnapLogic test automation:
Human-readable syntax: Tests are written in plain English, making them accessible to both technical and non-technical team members
Keyword-driven approach: Promotes reusability and reduces code duplication
Extensive ecosystem: Integrates seamlessly with databases, APIs, and various testing tools
Comprehensive reporting: Built-in HTML reports with detailed execution logs
CI/CD friendly: Easy integration with Jenkins, GitLab CI, and other automation platforms
The Power of Docker-Based Testing Infrastructure
One of the most powerful features of our framework is its Docker-based architecture.
Isolated Test Environments: Each test run operates in its own containerized environment
Groundplex Control: Automatically spin up and tear down Groundplex instances for testing
Database Services: Pre-configured containers for Oracle, PostgreSQL, MySQL, SQL Server, DB2, and more
Message Queue Systems: Integrated support for Kafka, ActiveMQ, and other messaging platforms
Storage Services: MinIO for S3-compatible object storage testing
This architecture allows below capabilities:
Test in production-like environments without affecting actual production systems
Quickly provision and tear down complete testing stacks
Run parallel tests with isolated resources
Ensure consistency across different testing environments
snaplogic-common-robot Library
Installation
The snaplogic-common-robot library is published on PyPI, making installation straightforward https://pypi.org/project/snaplogic-common-robot/
pip install snaplogic-common-robot
Core Components
The library provides the below components
SnapLogic APIs: Low-level keywords for direct API interactions
SnapLogic Keywords: High-level business-oriented keywords for common operations
Common Utilities: Database connections, file operations, and utility functions.
Dependency Libraries: Install all necessary dependency libraries to run Robot Framework tests for SnapLogic. These libraries support API testing, database operations, Docker container testing, JMS messaging, and AWS integration tools.
The following libraries are automatically installed as dependencies when you install snaplogic-common-robot, providing comprehensive API support. This library ecosystem continues to expand as we add support for additional features and capabilities.
Snaplogic RobotFramework-examples Repository
The snaplogic-robotframework-examples repository demonstrates how to build a complete testing framework using the snaplogic common library.https://github.com/SnapLogic/snaplogic-robotframework-examples
Framework Overview
Note: This project structure is continuously evolving! We're actively working to make the framework easier and more efficient to use,The structure is subject to change as we iterate on improvements to enhance developer experience and framework efficiency.
The framework follows a modular architecture with clear separation of concerns:
Configuration Layer
.env and .env.example manage environment variables for sensitive credentials and URLs
env_files/ folder have all details required for creating accounts
Makefile provides a central command interface for all build and test operations
docker-compose.yml orchestrates the entire multi-container environment with a single command
Build Automation
makefiles/ directory contains modular scripts organized by service type (databases, messaging, mocks)
Each service category has dedicated makefiles for independent lifecycle management
Infrastructure
docker/ holds Docker configurations for all services (Groundplex, Oracle, PostgreSQL, Kafka)
env_files/ stores service-specific environment variables to isolate configuration
Containerized approach ensures reproducible test environments across all systems
Test Organization
test/suite/ contains Robot Framework test suites organized by pipeline functionality
test/test_data/ provides input files and expected outputs for validation
Tests are grouped logically (Oracle, PostgreSQL+S3, Kafka) for easy maintenance
Pipeline Assets
src/pipelines/ stores the actual SnapLogic SLP files being tested
src/tools/ includes helper utilities and requirements.txt with Python dependencies
The snaplogic-common-robot library is installed via requirements.txt, providing reusable keywords
Test Reporting
Robot Framework automatically generates comprehensive test reports after each execution
report.html provides a high-level summary with pass/fail statistics and execution timeline
log.html offers detailed step-by-step execution logs with keyword-level information
output.xml contains structured test results in XML format for CI/CD integration
Reports include screenshots, error messages, and detailed traceability for debugging
All reports are timestamped and can be archived for historical analysis
Supporting Components
travis_scripts/ enables CI/CD automation for continuous testing
README/ holds project documentation and setup guides
Key Architecture Benefits
Modular design allows independent service management
Docker isolation ensures consistent test environments
Makefile automation simplifies complex operations
Clear directory structure improves maintainability
CI/CD integration enables automated testing workflows
Integration with CI/CD Pipelines
One of the most powerful aspects of our Robot Framework testing solution is its seamless integration with CI/CD pipelines. This enables continuous testing, ensuring that every code change is automatically validated against your SnapLogic integrations.
Why CI/CD Integration Matters
In modern DevOps practices, manual testing becomes a bottleneck. By integrating our Robot Framework tests into your CI/CD pipeline, you achieve:
Automatic Test Execution: Tests run automatically on every commit, pull request, or scheduled interval
Early Bug Detection: Issues are caught immediately, not days or weeks later in production
Consistent Testing: The same tests run every time, eliminating human error and variability
Fast Feedback Loop: Developers know within minutes if their changes broke existing integrations
Quality Gates: Prevent deployments if tests fail, ensuring only validated code reaches production
Jenkins is one of the most popular CI/CD tools, and integrating our Robot Framework tests is straightforward.
How It Works?
Stage 1: Prepare Environment Install SnapLogic common Robot library and required dependencies
Stage 2: Start Docker Services Launches Groundplex, Oracle DB, Kafka, and MinIO containers
Stage 3: Run Robot Framework Tests Execute test suites in parallel across 4 threads using pabot
Stage 4: Publish Test Results Generate HTML reports, XML results, and test artifacts and can upload to S3.
Stage 5: Send Notifications Distributes test results via Slack.
Post: Cleanup Tears down containers, removes temp files, archives logs
Slack Notifications include the below details
Our CI/CD pipeline automatically sends detailed test execution reports to Slack, providing immediate visibility into test results for the entire team.
HTML Reports have the below details
Robot Framework automatically generates comprehensive HTML reports after each test execution, providing detailed insights into test results, performance, and execution patterns.
Real-World Benefits
Here's what this means for your team:
For Developers
Push code with confidence - Tests run automatically
Get feedback in minutes - No waiting for QA cycles
Fix issues immediately - While the code is still fresh in your mind
For QA Teams
Focus on exploratory testing - Let automation handle regression
Better test coverage - Tests run on every single change
Clear reports - See exactly what's tested and what's not
Future Enhancements
We're continuously improving the framework with planned features include:
Enhanced support for more end points
Integration with cloud storage services
Advanced performance testing capabilities
Enhanced security testing features
Conclusion
The combination of snaplogic-common-robot library and snaplogic-robotframework-examples framework provides a powerful, scalable solution for SnapLogic test automation. By leveraging Docker's containerization capabilities, Robot Framework's simplicity, and SnapLogic's robust APIs, teams can:
Reduce testing time from hours to minutes
Increase test coverage with automated end-to-end scenarios
Improve reliability through consistent, repeatable tests
Enable continuous testing in CI/CD pipelines
Whether you're testing simple pipeline transformations or complex multi-system integrations, this framework provides the tools and patterns needed for comprehensive SnapLogic testing.
Getting Involved
We welcome contributions from the SnapLogic community! Here's how you can get involved:
Try the Framework: Install snaplogic-common-robot and run the example tests
Report Issues: Help us improve by reporting bugs or suggesting enhancements
Contribute Code: Submit pull requests with new keywords or test patterns
Share Your Experience: Let us know how you're using the framework in your organization
Resources
snaplogic-common-robot on PyPI: pip install snaplogic-common-robot https://pypi.org/project/snaplogic-common-robot/
snaplogic-robotframework-example repo: https://github.com/SnapLogic/snaplogic-robotframework-examples
Documentation: Comprehensive HTML documentation available after installation via README folder
Community Support: Join the discussion in SnapLogic Community forums
Start automating your SnapLogic tests today and experience the power of comprehensive, containerized test automation!
Questions? We're Here to Help!
We hope this comprehensive guide helps you get started with automated testing for your SnapLogic integrations. The combination of snaplogic-common-robot and Docker-based infrastructure provides a powerful foundation for building reliable, scalable test automation.
Have questions or need assistance implementing this framework?
The SLIM (SnapLogic Intelligent Modernization) team is here to support you! We'd love to hear about your use cases, help you overcome any challenges, or discuss how this framework can be customized for your specific needs.
Contact the SLIM Team:
Reach out to us directly through the SnapLogic Community forums
Tag us in your questions with @slim-team
Email us at: slim-team@snaplogic.com
We're committed to helping you achieve testing excellence and look forward to seeing how you leverage this framework to enhance your SnapLogic automation journey!
Happy Testing! The SLIM Team
15 days ago
8 MIN READ
Introduction
Since the inception of the Model Context Protocol (MCP), we've been envisioning and designing how it can be integrated into the SnapLogic platform. We've recently received a significant number of inquiries about MCP, and we're excited to share our progress, the features we'll be supporting, our release timeline, and how you can get started creating MCP servers and clients within SnapLogic. If you're interested, we encourage you to reach out!
Understanding the MCP Protocol
The MCP protocol allows tools, data resources, and prompts to be published by an MCP server in a way that Large Language Models (LLMs) can understand. This empowers LLMs to autonomously interact with these resources via an MCP client, expanding their capabilities to perform actions, retrieve information, and execute complex workflows.
MCP Protocol primarily supports:
Tools: Functions an LLM can invoke (e.g., data lookups, operational tasks).
Resources: File-like data an LLM can read (e.g., API responses, file contents).
Prompts: Pre-written templates to guide LLM interaction with the server.
Sampling (not widely used): Allows client-hosted LLMs to be used by remote MCP servers.
An MCP client can, therefore, request to list available tools, call specific tools, list resources, or read resource content from a server.
Transport and Authentication
MCP protocol offers flexible transport options, including STDIO or HTTP (SSE or Streamable-HTTP) for local deployments, and HTTP (SSE or Streamable-HTTP) for remote deployments.
While the protocol proposes OAuth 2.1 for authentication, an MCP server can also use custom headers for security.
Release Timeline
We're excited to bring MCP support to SnapLogic with two key releases:
August Release: MCP Client Support
We'll be releasing two new snaps: the MCP Function Generator Snap and the MCP Invoke Snap. These will be available in the AgentCreator Experimental (Beta) Snap Pack. With these Snaps, your SnapLogic agent can access the services and resources available on the public MCP server.
Late Q3 Release: MCP Server Support
Our initial MCP server support will focus on tool operations, including the ability to list tools and call tools. For authentication, it will support custom header-based authentication. Users will be able to leverage the MCP Server functionality by subscribing to this feature.
If you're eager to be among the first to test these new capabilities and provide feedback, please reach out to the Project Manager Team, at pm-team@snaplogic.com. We're looking forward to seeing what you build with SnapLogic MCP.
SnapLogic MCP Client
MCP Clients in SnapLogic enable users to connect to MCP servers as part of their Agent. An example can be connecting to the Firecrawl MCP server for a data scraping Agent, or other use cases that can leverage the created MCP servers.
The MCP Client support in SnapLogic consists of two Snaps, the MCP Function Generator Snap and the MCP Invoke Snap. From a high-level perspective, the MCP Function generator Snap allows users to list available tools from an MCP server, and the MCP Invoke Snap allows users to perform operations such as call tools, list resources, and read resources from an MCP server.
Let’s dive into the individual pieces.
MCP SSE Account
To connect to an MCP Server, we will need an account to specify the URI of the server to connect to.
Properties
URI
The URI of the server to connect to. Don’t need to include the /sse path
Additional headers
Additional HTTP headers to be sent to the server
Timeout
The timeout value in seconds, if the result is not returned within the timeout, the Snap will return an error.
MCP Function Generator Snap
The MCP Function Generator Snap enables users to retrieve the list of tools as SnapLogic function definitions to be used in a Tool Calling Snap.
Properties
Account
An MCP SSE account is required to connect to an MCP Server.
Expose Tools
List all available tools from an MCP server as SnapLogic function definitions
Expose Resources
Add list_resources, read_resource as SnapLogic function definitions to allow LLMs to use resources/read and resources/list (MCP Resources).
Definitions for list resource and read resource
[ { "sl_type": "function", "name": "list_resources", "description": "This function lists all available resources on the MCP server. Return a list of resources with their URIs.", "strict": false, "sl_tool_metadata": { "operation": "resources/list" } }, { "sl_type": "function", "name": "read_resource", "description": "This function returns the content of the resource from the MCP server given the URI of the resource.", "strict": false, "sl_tool_metadata": { "operation": "resources/read" }, "parameters": [ { "name": "uri", "type": "STRING", "description": "Unique identifier for the resource", "required": true } ] } ]
MCP Invoke Snap
The MCP Invoke Snap enables users to perform operations such as tools/call, resources/list, and resources/read to an MCP server.
Properties
Account
An account is required to use the MCP Invoke Snap
Operation
The operation to perform on the MCP server. The operation must be one of tools/call, resources/list, or resources/read
Tool Name
The name of the tool to call. Only enabled and required when the operation is tools/call
Parameters
The parameters to be added to the operation. Only enabled for resources/read and tools/call. Required for resources/read, and optional for tools/call, based on the tool.
MCP Agents in pipeline action
MCP Agent Driver pipeline
An MCP Agent Driver pipeline is like any other MCP Agent pipeline; we’ll need to provide the system prompt, user prompt, and run it with the PipeLoop Snap.
MCP Agent Worker pipeline
Here’s an example of an MCP Agent with a single MCP Server connection. The MCP Agent Worker is connected to one MCP Server.
MCP Client Snaps can be used together with AgentCreator Snaps, such as the Multi-Pipeline Function Generator and Pipeline Execute Snap, as SnapLogic Functions, tools. This allows users to use tools provided by MCP servers and internal tools, without sacrificing safety and freedom when building an Agent.
Agent Worker with MCP Client Snaps
SnapLogic MCP Server
In SnapLogic, an MCP Server allows you to expose SnapLogic pipelines as dynamic tools that can be discovered and invoked by language models or external systems.
By registering an MCP Server, you effectively provide a API that language models and other clients can use to perform operations such as data retrieval, transformation, enrichment, or automation, all orchestrated through SnapLogic pipelines.
For the initial phase, we'll support connections to the server via HTTP + SSE.
Core Capabilities
The MCP Server provides two core capabilities.
The first is listing tools, which returns structured metadata that describes the available pipelines. This metadata includes the tool name, a description, the input schema in JSON Schema format, and any additional relevant information. This allows clients to dynamically discover which operations are available for invocation.
The second capability is calling tools, where a specific pipeline is executed as a tool using structured input parameters, and the output is returned.
Both of these operations—tool listing and tool calling—are exposed through standard JSON-RPC methods, specifically tools/list and tools/call, accessible over HTTP.
Prerequisite
You'll need to prepare your tool pipelines in advance. During the server creation process, these can be added and exposed as tools for external LLMs to use.
MCP Server Pipeline Components
A typical MCP server pipeline consists of four Snaps, each with a dedicated role:
1. Router
What it does: Routes incoming JSON requests—which differ from direct JSON-RPC requests sent by an MCP client—to either the list tools branch or the call tool branch.
How: Examines the request payload (typically the method field) to determine which action to perform. 2. Multi-Pipeline Function Generator (Listing Tools)
What it does: Converts a list of pipeline references into tool metadata. This is where you define the pipelines you want the server to expose as tools.
Output: For each pipeline, generates:
Tool name
Description
Parameters (as JSON Schema)
Other metadata
Purpose: Allows clients (e.g., an LLM) to query what tools are available without prior knowledge.
3. Pipeline Execute (Calling Tools)
What it does: Dynamically invokes the selected SnapLogic pipeline and returns structured outputs.
How: Accepts parameters encoded in the request body, maps them to the pipeline’s expected inputs, and executes the pipeline.
Purpose: Provides flexible runtime execution of tools based on user or model requests.
4. Union
What it does: Merges the result streams from both branches (list and call) into a single output stream for consistent response formatting.
Request Flows
Below are example flows showing how requests are processed:
🟢 tools/list
Client sends a JSON-RPC request with method = "tools/list".
Router directs the request to the Multi-Pipeline Function Generator.
Tool metadata is generated and returned in the response.
Union Snap merges and outputs the content.
✅ Result: The client receives a JSON list describing all available tools.
�� tools/call
Client sends a JSON-RPC request with method = "tools/call" and the tool name + parameters.
Router sends this to the Pipeline Execute Snap.
The selected pipeline is invoked with the given parameters.
Output is collected and merged via Union.
✅ Result: The client gets the execution result of the selected tool.
Registering an MCP Server
Once your MCP server pipeline is created:
Create a Trigger Task and Register as an MCP Server
Navigate to the Designer > Create Trigger Task
Choose a Groundplex. (Note: This capability currently requires a Groundplex, not a Cloudplex.)
Select your MCP pipeline.
Click Register as MCP server
Configure node and authentication.
Find your MCP Server URL
Navigate to the Manager > Tasks
The Task Details page exposes a unique HTTP endpoint.
This endpoint is treated as your MCP Server URL.
After registration, clients such as AI models or orchestration engines can interact with the MCP Server by calling the /tools/list endpoint to discover the available tools, and the /tools/call endpoint to invoke a specific tool using a structured JSON payload.
Connect to a SnapLogic MCP Server from a Client
After the MCP server is successfully published, using the SnapLogic MCP server is no different from using other MCP servers running in SSE mode. It can be connected to by any MCP client that supports SSE mode; all you need is the MCP Server URL (and the Bearer Token if authentication is enabled during server registration).
Configuration
First, you need to add your MCP server in the settings of the MCP client. Taking Claude Desktop as an example, you'll need to modify your Claude Desktop configuration file. The configuration file is typically located at:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add your remote MCP server configuration to the mcpServers section:
{ "mcpServers": { "SL_MCP_server": { "command": "npx", "args": [ "mcp-remote", "http://devhost9000.example.com:9000/mcp/6873ff343a91cab6b00014a5/sse", "--header", "Authorization: Bearer your_token_here" ] } } }
Key Components
Server Name: SL_MCP_server - A unique identifier for your MCP server
Command: npx - Uses the Node.js package runner to execute the mcp-remote package
URL: The SSE endpoint URL of your remote MCP server (note the /sse suffix)
Authentication: Use the --header flag to include authorization tokens if the server enabled authentication
Requirements
Ensure you have Node.js installed on your system, as the configuration uses npx to run the mcp-remote package. Replace the example URL and authorization token with your actual server details before saving the configuration.
After updating the configuration file, restart Claude Desktop for the changes to take effect.
To conclude, the MCP Server in SnapLogic is a framework that allows you to expose pipelines as dynamic tools accessible through a single HTTP endpoint. This capability is designed for integration with language models and external systems that need to discover and invoke SnapLogic workflows at runtime. MCP Servers make it possible to build flexible, composable APIs that return structured results, supporting use cases such as conversational AI, automated data orchestration, and intelligent application workflows.
Conclusion
SnapLogic's integration of the MCP protocol marks a significant leap forward in empowering LLMs to dynamically discover and invoke SnapLogic pipelines as sophisticated tools, transforming how you build conversational AI, automate complex data orchestrations, and create truly intelligent applications. We're excited to see the innovative solutions you'll develop with these powerful new capabilities.
2 months ago
7 MIN READ
Introduction
OpenAI announced the Responses API, their most advanced and versatile interface for building intelligent AI applications. Supporting both text and image inputs with rich text outputs, this API enables dynamic, stateful conversations that remember and build on previous interactions, making AI experiences more natural and context-aware. It also unlocks powerful capabilities through built-in tools such as web search, file search, code interpreter, and more, while enabling seamless integration with external systems via function calling. Its event-driven design delivers clear, structured updates at every step, making it easier than ever to create sophisticated, multi-step AI workflows.
Key features include:
Stateful conversations via the previous response ID
Built-in tools like web search, file search, code interpreter, MCP, and others
Access to advanced models available exclusively, such as o1-pro
Enhanced support for reasoning models with reasoning summaries and efficient context management through previous response ID or encrypted reasoning items
Clear, event-based outputs that simplify integration and control
While the Chat Completions API remains fully supported and widely used, OpenAI plans to retire the Assistants API in the first half of 2026.
To support the adoption of the Responses API, two new Snaps have been introduced:
OpenAI Chat Completions ⇒ OpenAI Responses API Generation
OpenAI Tool Calling ⇒ OpenAI Responses API Tool Calling
Both Snaps are fully compatible with existing upstream and downstream utility Snaps, including the OpenAI Prompt Generator, OpenAI Multimodal Content Generator, all Function Generators (Multi-Pipeline, OpenAPI, and APIM), the Function Result Generator, and the Message Appender. This allows existing pipelines and familiar development patterns to be reused while gaining access to the advanced features of the Responses API.
OpenAI Responses API Generation
The OpenAI Responses API Generation Snap is designed to support OpenAI’s newest Responses API, enabling more structured, stateful, and tool-augmented interactions. While it builds upon the familiar interface of the Chat Completions Snap, several new properties and behavioral updates have been introduced to align with the Responses API’s capabilities.
New properties
Message: The input sent to the LLM. This field replaces the previous Use message payload, Message payload, and Prompt properties in the OpenAI Chat Completions Snap, consolidating them into a single input. It removes ambiguity between "prompt" as raw text and as a template, and supports both string and list formats.
Previous response ID: The unique ID of the previous response to the model. Use this to create multi-turn conversations.
Model parameters
Reasoning summary: For reasoning models, provides a summary of the model’s reasoning process, aiding in debugging and understanding the model's reasoning process. The property can be none, auto, or detailed.
Advanced prompt configurations
Instructions: Applied only to the current response, making them useful for dynamically swapping instructions between turns. To persist instructions across turns when using previous_response_id, the developer message in the OpenAI Prompt Generator Snap should be used.
Advanced response configurations
Truncation: Defines how to handle input that exceeds the model’s context window. auto allows the model to truncate the middle of the conversation to fit, while disabled (default) causes the request to fail with a 400 error if the context limit is exceeded.
Include reasoning encrypted content: Includes an encrypted version of reasoning tokens in the output, allowing reasoning items to persist when the store is disabled.
Built-in tools
Web search: Enables the model to access up-to-date information from the internet to answer queries beyond its training data.
Web search type
Search context size
User location: an approximate user location including city, region, country, and timezone to deliver more relevant search results.
File search: Allows the model to retrieve information from documents or files.
Vector store IDs
Maximum number of results
Include search results: Determines whether raw search results are included in the response for transparency or debugging.
Ranker
Score threshold
Filters: Additional metadata-based filters to refine search results. For more details on using filters, see Metadata Filtering.
Advanced tool configuration
Tool choice: A new option, SPECIFY A BUILT-IN TOOL, allows specifying that the model should use a built-in tool to generate a response.
Note that the OpenAI Responses API Generation Snap does not support the response count or stop sequences properties, as these are not available in the Responses API. Additionally, the message user name, which may be specified in the Prompt Generator Snap, is not supported and will be ignored if included.
Model response of Chat Completions vs Responses API
Chat Completions API
Responses API
The Responses API introduces an event-driven output structure that significantly enhances how developers build and manage AI-powered applications compared to the traditional Chat Completions API. While the Chat Completions API returns a single, plain-text response within the choices array, the Responses API provides an output array containing a sequence of semantic event items—such as reasoning, message, function_call, web_search_call, and more—that clearly delineate each step in the model's reasoning and actions. This structured approach allows developers to easily track and interpret the model's behavior, facilitating more robust error handling and smoother integration with external tools. Moreover, the response from the Responses API includes the model parameters settings, providing additional context for developers.
Pipeline examples
Built-in tool: web search
This example demonstrates how to use the built-in web search tool. In this pipeline, the user’s location is specified to ensure the web search targets relevant geographic results.
System prompt: You are a friendly and helpful assistant. Please use your judge to decide whether to use the appropriate tools or not to answer questions from the user.
Prompt: Can you recommend 2 good sushi restaurants near me?
Output:
As a result, the output contains both a web search call and a message. The model uses the web search to find and provide recommendations based on current data, tailored to the specified location.
Built-in tool: File search
This example demonstrates how the built-in file search tool enables the model to retrieve information from documents stored in a vector store during response generation. In this case, the file wildfire_stats.pdf has been uploaded. You can create and manage vector stores through the Vector Store management page.
Prompt: What is the number of Federal wildfires in 2018
Output:
The output array contains a file_search_call event, which includes search results in its results field. These results provide matched text, metadata, and relevance scores from the vector store. This is followed by a message event, where the model uses the retrieved information to generate a grounded response. The presence of detailed results in the file_search_call is enabled by selecting the Include file search results option.
OpenAI Responses API Tool Calling
The OpenAI Responses API Tool Calling Snap is designed to support function calling using OpenAI’s Responses API. It works similarly to the OpenAI Tool Calling Snap (which uses the Chat Completions API), but is adapted to the event-driven response structure of the Responses API and supports stateful interactions via the previous response ID. While it shares much of its configuration with the Responses API Generation Snap, it is purpose-built for workflows involving function calls.
Existing LLM agent pipeline patterns and utility Snaps—such as the Function Generator and Function Result Generator—can continue to be used with this Snap, just as with the original OpenAI Tool Calling Snap. The primary difference lies in adapting the Snap configuration to accommodate the Responses API’s event-driven output, particularly the structured function_call event item in the output array.
The Responses API Tool Calling Snap provides two output views, similar to the OpenAI Tool Calling Snap, with enhancements to simplify building agent pipelines and support stateful interactions using the previous response ID:
Model response view: The complete API response, including extra fields:
messages: an empty list if store is enabled, or the full message history—including messages payload and model response—if disabled (similar to the OpenAI Tool Calling Snap). When using stateful workflows, message history isn’t needed because the previous response ID is used to maintain context.
has_tool_call: a boolean indicating whether the response includes a tool call. Since the Responses API no longer includes the finish_reason: "tool_calls" field, this new field makes it easier to create stop conditions in the pipeloop Snap within the agent driver pipeline.
Tool call view: Displays the list of function calls made by the model during the interaction.
Tool Call View of Chat Completions vs Responses API
Uses id as the function call identifier when sending back the function result.
Tool call properties (name, arguments) are nested inside the function field.
Each tool call includes: • id: the unique event ID • call_id: used to reference the function call when returning the result
The tool call structure is flat — name and arguments are top-level fields.
Building LLM Agent Pipelines
To build LLM agent pipelines with the OpenAI Responses API Tool Calling Snap, you can reuse the same agent pipeline pattern described in Introducing Tool Calling Snaps and LLM Agent Pipelines. Only minor configuration changes are needed to support the Responses API.
Agent Driver Pipeline
The primary change is in the PipeLoop Snap configuration, where the stop condition should now check the has_tool_call field, since the Responses API no longer includes the finish_reason:"tool_calls".
Agent Worker Pipeline
Fields mapping
A Mapper Snap is used to prepare the related fields for the OpenAI Responses API Tool Calling Snap.
OpenAI Responses API Tool Calling
The key changes are in this Snap’s configuration to support the Responses API’s stateful interactions. There are two supported approaches:
Option 1: Use Store (Recommended) Leverages the built-in state management of the Responses API.
Enable Store
Use Previous Response ID
Send only the function call results as the input messages for the next round. (messages field in the Snap’s output will be an empty array, so you can still use it in the Message Appender Snap to collect tool results.)
Option 2: Maintain Conversation History in Pipeline Similar to the approach used in the Chat Completions API.
Disable Store
Include the full message history in the input (messages field in the Snap’s output contains message history)
(Optional) Enable Include Reasoning Encrypted Content (for reasoning models) to preserve reasoning context efficiently
OpenAI Function Result Generator
As explained in Tool Call View of Chat Completions vs Responses API section, the Responses API includes both an id and a call_id. You must use the call_id to construct the function call result when sending it back to the model.
Conclusion
The OpenAI Responses API makes AI workflows smarter and more adaptable, with stateful interactions and built-in tools. SnapLogic’s OpenAI Responses API Generation and Tool Calling Snaps bring these capabilities directly into your pipelines, letting you take advantage of advanced features like built-in tools and event-based outputs with only minimal adjustments. By integrating these Snaps, you can seamlessly enhance your workflows and fully unlock the potential of the Responses API.
2 months ago
7 MIN READ
Introduction
OpenAI announced the Responses API, their most advanced and versatile interface for building intelligent AI applications. Supporting both text and image inputs with rich text outputs, this API enables dynamic, stateful conversations that remember and build on previous interactions, making AI experiences more natural and context-aware. It also unlocks powerful capabilities through built-in tools such as web search, file search, code interpreter, and more, while enabling seamless integration with external systems via function calling. Its event-driven design delivers clear, structured updates at every step, making it easier than ever to create sophisticated, multi-step AI workflows.
Key features include:
Stateful conversations via the previous response ID
Built-in tools like web search, file search, code interpreter, MCP, and others
Access to advanced models available exclusively, such as o1-pro
Enhanced support for reasoning models with reasoning summaries and efficient context management through previous response ID or encrypted reasoning items
Clear, event-based outputs that simplify integration and control
While the Chat Completions API remains fully supported and widely used, OpenAI plans to retire the Assistants API in the first half of 2026.
To support the adoption of the Responses API, two new Snaps have been introduced:
OpenAI Chat Completions ⇒ OpenAI Responses API Generation
OpenAI Tool Calling ⇒ OpenAI Responses API Tool Calling
Both Snaps are fully compatible with existing upstream and downstream utility Snaps, including the OpenAI Prompt Generator, OpenAI Multimodal Content Generator, all Function Generators (Multi-Pipeline, OpenAPI, and APIM), the Function Result Generator, and the Message Appender. This allows existing pipelines and familiar development patterns to be reused while gaining access to the advanced features of the Responses API.
OpenAI Responses API Generation
The OpenAI Responses API Generation Snap is designed to support OpenAI’s newest Responses API, enabling more structured, stateful, and tool-augmented interactions. While it builds upon the familiar interface of the Chat Completions Snap, several new properties and behavioral updates have been introduced to align with the Responses API’s capabilities.
New properties
Message: The input sent to the LLM. This field replaces the previous Use message payload, Message payload, and Prompt properties in the OpenAI Chat Completions Snap, consolidating them into a single input. It removes ambiguity between "prompt" as raw text and as a template, and supports both string and list formats.
Previous response ID: The unique ID of the previous response to the model. Use this to create multi-turn conversations.
Model parameters
Reasoning summary: For reasoning models, provides a summary of the model’s reasoning process, aiding in debugging and understanding the model's reasoning process. The property can be none, auto, or detailed.
Advanced prompt configurations
Instructions: Applied only to the current response, making them useful for dynamically swapping instructions between turns. To persist instructions across turns when using previous_response_id, the developer message in the OpenAI Prompt Generator Snap should be used.
Advanced response configurations
Truncation: Defines how to handle input that exceeds the model’s context window. auto allows the model to truncate the middle of the conversation to fit, while disabled (default) causes the request to fail with a 400 error if the context limit is exceeded.
Include reasoning encrypted content: Includes an encrypted version of reasoning tokens in the output, allowing reasoning items to persist when the store is disabled.
Built-in tools
Web search: Enables the model to access up-to-date information from the internet to answer queries beyond its training data.
Web search type
Search context size
User location: an approximate user location including city, region, country, and timezone to deliver more relevant search results.
File search: Allows the model to retrieve information from documents or files.
Vector store IDs
Maximum number of results
Include search results: Determines whether raw search results are included in the response for transparency or debugging.
Ranker
Score threshold
Filters: Additional metadata-based filters to refine search results. For more details on using filters, see Metadata Filtering.
Advanced tool configuration
Tool choice: A new option, SPECIFY A BUILT-IN TOOL, allows specifying that the model should use a built-in tool to generate a response.
Note that the OpenAI Responses API Generation Snap does not support the response count or stop sequences properties, as these are not available in the Responses API. Additionally, the message user name, which may be specified in the Prompt Generator Snap, is not supported and will be ignored if included.
Model response of Chat Completions vs Responses API
Chat Completions API
Responses API
The Responses API introduces an event-driven output structure that significantly enhances how developers build and manage AI-powered applications compared to the traditional Chat Completions API. While the Chat Completions API returns a single, plain-text response within the choices array, the Responses API provides an output array containing a sequence of semantic event items—such as reasoning, message, function_call, web_search_call, and more—that clearly delineate each step in the model's reasoning and actions. This structured approach allows developers to easily track and interpret the model's behavior, facilitating more robust error handling and smoother integration with external tools. Moreover, the response from the Responses API includes the model parameters settings, providing additional context for developers.
Pipeline examples
Built-in tool: web search
This example demonstrates how to use the built-in web search tool. In this pipeline, the user’s location is specified to ensure the web search targets relevant geographic results.
System prompt: You are a friendly and helpful assistant. Please use your judge to decide whether to use the appropriate tools or not to answer questions from the user.
Prompt: Can you recommend 2 good sushi restaurants near me?
Output:
As a result, the output contains both a web search call and a message. The model uses the web search to find and provide recommendations based on current data, tailored to the specified location.
Built-in tool: File search
This example demonstrates how the built-in file search tool enables the model to retrieve information from documents stored in a vector store during response generation. In this case, the file wildfire_stats.pdf has been uploaded. You can create and manage vector stores through the Vector Store management page.
Prompt: What is the number of Federal wildfires in 2018
Output:
The output array contains a file_search_call event, which includes search results in its results field. These results provide matched text, metadata, and relevance scores from the vector store. This is followed by a message event, where the model uses the retrieved information to generate a grounded response. The presence of detailed results in the file_search_call is enabled by selecting the Include file search results option.
OpenAI Responses API Tool Calling
The OpenAI Responses API Tool Calling Snap is designed to support function calling using OpenAI’s Responses API. It works similarly to the OpenAI Tool Calling Snap (which uses the Chat Completions API), but is adapted to the event-driven response structure of the Responses API and supports stateful interactions via the previous response ID. While it shares much of its configuration with the Responses API Generation Snap, it is purpose-built for workflows involving function calls.
Existing LLM agent pipeline patterns and utility Snaps—such as the Function Generator and Function Result Generator—can continue to be used with this Snap, just as with the original OpenAI Tool Calling Snap. The primary difference lies in adapting the Snap configuration to accommodate the Responses API’s event-driven output, particularly the structured function_call event item in the output array.
The Responses API Tool Calling Snap provides two output views, similar to the OpenAI Tool Calling Snap, with enhancements to simplify building agent pipelines and support stateful interactions using the previous response ID:
Model response view: The complete API response, including extra fields:
messages: an empty list if store is enabled, or the full message history—including messages payload and model response—if disabled (similar to the OpenAI Tool Calling Snap). When using stateful workflows, message history isn’t needed because the previous response ID is used to maintain context.
has_tool_call: a boolean indicating whether the response includes a tool call. Since the Responses API no longer includes the finish_reason: "tool_calls" field, this new field makes it easier to create stop conditions in the pipeloop Snap within the agent driver pipeline.
Tool call view: Displays the list of function calls made by the model during the interaction.
Tool Call View of Chat Completions vs Responses API
Uses id as the function call identifier when sending back the function result.
Tool call properties (name, arguments) are nested inside the function field.
Each tool call includes: • id: the unique event ID • call_id: used to reference the function call when returning the result
The tool call structure is flat — name and arguments are top-level fields.
Building LLM Agent Pipelines
To build LLM agent pipelines with the OpenAI Responses API Tool Calling Snap, you can reuse the same agent pipeline pattern described in Introducing Tool Calling Snaps and LLM Agent Pipelines. Only minor configuration changes are needed to support the Responses API.
Agent Driver Pipeline
The primary change is in the PipeLoop Snap configuration, where the stop condition should now check the has_tool_call field, since the Responses API no longer includes the finish_reason:"tool_calls".
Agent Worker Pipeline
Fields mapping
A Mapper Snap is used to prepare the related fields for the OpenAI Responses API Tool Calling Snap.
OpenAI Responses API Tool Calling
The key changes are in this Snap’s configuration to support the Responses API’s stateful interactions. There are two supported approaches:
Option 1: Use Store (Recommended) Leverages the built-in state management of the Responses API.
Enable Store
Use Previous Response ID
Send only the function call results as the input messages for the next round. (messages field in the Snap’s output will be an empty array, so you can still use it in the Message Appender Snap to collect tool results.)
Option 2: Maintain Conversation History in Pipeline Similar to the approach used in the Chat Completions API.
Disable Store
Include the full message history in the input (messages field in the Snap’s output contains message history)
(Optional) Enable Include Reasoning Encrypted Content (for reasoning models) to preserve reasoning context efficiently
OpenAI Function Result Generator
As explained in Tool Call View of Chat Completions vs Responses API section, the Responses API includes both an id and a call_id. You must use the call_id to construct the function call result when sending it back to the model.
Conclusion
The OpenAI Responses API makes AI workflows smarter and more adaptable, with stateful interactions and built-in tools. SnapLogic’s OpenAI Responses API Generation and Tool Calling Snaps bring these capabilities directly into your pipelines, letting you take advantage of advanced features like built-in tools and event-based outputs with only minimal adjustments. By integrating these Snaps, you can seamlessly enhance your workflows and fully unlock the potential of the Responses API.
3 months ago