Celigo not returning output from SQL stored procedure

Integrator.io
, ,
1

I'm trying to call a SQL Server stored procedure from a Celigo import flow, and I can’t get Celigo to return the output value. The same stored procedure returns the correct output when I run it directly in SSMS, but when Celigo runs it, the response comes back empty, so there's nothing to map in Response Mapping.

What I've checked so far:

  • Running the stored procedure directly in SQL Server works and returns the expected output.

  • The Celigo SQL connection is fine — the flow runs without errors.

  • I set up Response Mapping to capture the return value, but Celigo isn’t receiving anything back.

  • The stored procedure uses an OUTPUT parameter.

What I’m wondering:

  • Does Celigo not support reading OUTPUT parameters from stored procedures?

  • Does the procedure need to SELECT a result set instead?

  • Is there a specific return format Celigo expects?

Here’s the SQL I'm executing inside Celigo:

DECLARE @ID INT;

EXEC [SAMPLE_DB]
    @IN_MessageID = '1234567',
    @IN_MessageType = 'Message',
    @ID = @ID OUTPUT;

SELECT @ID AS UUID;

In SSMS, this returns a value for UUID.
In Celigo, the output is completely empty.

Has anyone gotten Celigo to capture stored procedure output successfully? Do I need to change the stored procedure to explicitly return a table with SELECT, or is there another way Celigo expects this to be formatted?

Any examples or guidance would be super helpful.

2

Are you using a SQL Server import or lookup? If using an import, can you try a lookup instead and see if you get anything?

3

I've had a case open since August of 2025, same problem basically. Celigo Import into SQL databases do not populate the _json object in the response. I've duplicated this in both MS SQL and PGSQL.

When I tried the same SQL statement in a Lookup block instead, the Lookup correctly populated the data array in the response. This means the server is at least returning something expected.

I've opened a second case with the PGSQL issue because the workaround of using a Lookup block causes a side effect of the connection hanging open, despite the concurrency setting of 2, the Celigo on-prem Agent will instantly eat 100 connections in 'idle' state, which locks out everyone else from the PGSQL database except admins.

4

Hey Troy, we’ll see what we can do. The reason it’s currently not returned is because, in the past, customers have put select statements in their queries (since we don’t validate anything on queries), and it causes memory overloads in those cases since imports aren’t meant for that.

That being said, I’m sure we can find a solution, but I wanted to let you know that’s why it’s currently not in place.