nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

API Flow vs Data Flow : Best practices for integration

Denis MARETTE

Hi,
I need to develop an integration in ION with a third-party application.
I have exposed a new API suite in ION API Gateway that corresponds to this application.
Among these APIs, one of them—when executed in ION API Gateway using the “Try” button—requires three input parameters, and a fourth parameter allows the user to upload a file from their computer to send it to the third-party application.
All of this works perfectly.

However, I’m having trouble modeling the sequence of all the steps I’ve identified.
In an API Flow, it seems I’m unable to pass a document as a Base64-encoded variable to transmit the equivalent of the file’s content, as I was able to do with the “Try” button in ION API Gateway. Presumably, this is a limitation of ION .

Instead, I should consider designing my workflow as a data flow.
But in that case, I run into other design limitations. In particular, I’d like to be able to include decision steps to handle technical or functional error codes from API calls. But in a data flow, this seems quite limited.

Could you share some best practices for addressing this type of requirement?

Regards,
Denis

Find more posts tagged with

Accepted answers

Brandon Watson

<?xml version="1.0" encoding="UTF-8"?>
<jsonTransform
    xmlns="http://www.infor.com/ion/api"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" name="Transform-Base64-Payload-to-Binary-with-Octet-Stream-Content-Type" displayName="Transform Base64 Payload to Binary with Octet-Stream Content-Type" enabled="true" continueOnError="false">
    <matcher matchKind="string" matchValue="" matchAction="apply"></matcher>
    <transformations>
        <transform kind="handlebars" outputType="application/octet-stream">
            <![CDATA[{{base64Decode payload}}]]>
        </transform>
    </transformations>
</jsonTransform>

{"parameter1":"value1","parameter2":"value2","parameter3":"value3","payload":"base64-encoded-string-here"}

The application/octet-stream upload is one of the most challenging format types to work with, primarily because you have to send the whole binary file as a bod to that endpoint. There are no values to be reached in the binary file due to this. In my experience you have two options, one is the Custom Headers as Carsten mentioned, but I had trouble with this route and the limit of customer headers available. I was not able to solve it in API flow nor Data Flow. The second is an endpoint Policy. You will have to create new swagger doc for the endpoint so it accepts the json schema instead, but this could allow you to have parameters passed and the binary file.

All comments

Denis MARETTE

Please find the description of my use case.

It is about an integration between IDM and SharePoint.

At some point in the sequence of steps of this data flow, I have to call the Microsoft Graph API :

CustomerApi/msgraph/microsoft-graph/sites/{siteId}/drives/{driveId}/root:/{filePath}:/content.

This API allows you to upload a document to a library on a SharePoint site.

Here is the swagger excerpt corresponding to this transaction:

I have already tested it interactively in ION API Gateway.

This requires 3 input parameters and leads me to download a file from my workstation.

When I run it, everything goes smoothly and my file has been successfully uploaded to SharePoint.

Now, when I want to model the equivalent of this step in my data Flow using an API connection point, I run into a difficulty in knowing how to configure it to pass these parameters of a different nature to it.

On the one hand, I have my binary content of IDM in a document of type ANY.

I also stored in a JSON structured document the siteId, driveId, filePath parameters

But in the connection point setting, I don't have the option to make these settings dynamic.

Does my use case represent a limitation of ION integration?

Fabiano Silva

You need to change the type of Document to Receive like XML or JSON, and use the XPath.

Denis MARETTE

But I can't do that because I have to keep the input document as a binary type in order to send it to the API.
If I switch the input document and reference my JSON, I’ll have access to my parameter values using Path.
But I’ll lose access to my binary content.
That’s exactly my problem—I’m kind of going in circles.
I don’t see how to reconcile these two requirements

Carsten Steinhoefel

You could add custom headers to your document schema and add the values in a script step before the API call.

Denis MARETTE

@Carsten Steinhoefel
Thank you for sharing this idea.
I've tried to figure out how to implement it, but I always end up back at my original problem.
Even if I were able to pass custom parameters in the header (which I haven't been able to do yet), I'd still be stuck because those values aren't accessible when I make my API call.

Brandon Watson

<?xml version="1.0" encoding="UTF-8"?>
<jsonTransform
    xmlns="http://www.infor.com/ion/api"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" name="Transform-Base64-Payload-to-Binary-with-Octet-Stream-Content-Type" displayName="Transform Base64 Payload to Binary with Octet-Stream Content-Type" enabled="true" continueOnError="false">
    <matcher matchKind="string" matchValue="" matchAction="apply"></matcher>
    <transformations>
        <transform kind="handlebars" outputType="application/octet-stream">
            <![CDATA[{{base64Decode payload}}]]>
        </transform>
    </transformations>
</jsonTransform>

{"parameter1":"value1","parameter2":"value2","parameter3":"value3","payload":"base64-encoded-string-here"}

Denis MARETTE

@Brandon Watson Thank you for the tips and the explanation.
I will try the second option. I will keep you informed.

Carsten Steinhoefel

You should be able to use Ctrl-Space in the Value field and select one of the Headers if I remember correctly.

Copyright © 2026 Infor. All rights reserved.