I think the issue here is actually that SaaS connectors need to be created using multiple API calls because there are certain aspects of the source configuration which are required (cluster
and spConnectorSpecId
) but which can only be determined after the source has been created and connection parameters have been saved.
First, the correct initial POST payload for creating a SaaS connector-based source should be much more lightweight than what you send when you create a VA-based source. For Okta, it should look like the below:
{
"name": "TestOktaSaasThroughAPI",
"description": "TestOktaSaasThroughAPI",
"connector": "oktasaas",
"owner":
{
"id": "2c9180866653956401665ebf3bf83509",
"name": "owner.name",
"type": "IDENTITY"
}
}
This will return as an API response a fuller representation of the source configuration, including spConnectorInstanceId
, which is a unique entry in the connectorAttributes
map and is required for the connectivity layer to find the right source-connector pair.
What is still missing for this source to run a test connection, though, is the cluster
configuration, which is still needed even though this is a SaaS connector because there is an internal “proxy” cluster that gets assigned to the SaaS connector when you provide authentication information. Thus, a second PATCH call is needed:
[
{
"op": "add",
"path": "/connectorAttributes/authttype",
"value": "API Token"
},
{
"op": "add",
"path": "/connectorAttributes/host",
"value": "https://<tenant>.okta.com"
},
{
"op": "add",
"path": "/connectorAttributes/apiToken",
"value": "<token>"
}
]
You’ll notice that the response now includes a valid cluster
object with an instance of the sp_connect_proxy_cluster
:
"cluster": {
"type": "CLUSTER",
"id": "2c91808780f6c51601812af862a63c07",
"name": "sp_connect_proxy_cluster"
}
At this point, your source should be in a valid state to run a test connection.