POSTing deep structures

Is it possible to post an object graph more than one level deep natively using the API?

For example, in my application there are Qualifications which comprise Pathways which are themselves a collection of Units:

Qualification --(1:many)–> Pathway --(many:many)–> Unit

The relationship between Pathway and Unit is represented by a many:many table (Pathway Unit) which is just two ID columns.

I can POST a new Qualification and simultaneously create a new Pathway using the tutorial instructions, however if I also try and create the Pathway Unit record at this time nothing seems to happen. The Unit record I’m trying to link to already exists.

I don’t get an error from the API, the call succeeds but only seems to create the structure one level deep. I’m guessing that the API simply doesn’t support this use-case and I need to use a stored procedure, but I wanted to ask first to make sure I’m not simply missing something.

adam, that’s correct. we only support one level of relationship on those calls.
Depending on how your data is structured it may be possible for you to post to the middle level (Pathway) and therefore add the qualification and unit at the same time, as they are each just 1 level from the Pathway.
Otherwise, stored procedure is the way to go.

Hi Drew,

That is a great idea actually, however it doesn’t seem to allow me to do it. The Pathway has a belongs_to relationship with Qualification which makes the qualification_id field mandatory.

So when I try the following request in swagger:

"resource": [{

	"name": "Primary pathway",
	"cid_qualification_by_qualification_id": {
		"name": "test qualification",
		"type_id": 1
	"cid_pathway_unit_by_pathway_id": [{
		"unit_id": 1


I receive the error message “Required field ‘qualification_id’ can not be NULL.”. This does make sense because Pathway is composite to Qualification.

It’s a shame because that is a really neat way of working around the limitation.

Yeah, I was afraid of that. Seems like stored procedure is definitely the way to go then.

No problem, it was a good idea anyway. Thanks for the info.