Short answer. Send item_group_id. It is the field Meta documents for grouping variants — sizes, colours, patterns of one product — in a catalog feed and in the items_batch API, and Meta maps it to retailer_product_group_id itself once it has your data. retailer_product_group_id is a field you read back from the product, not one you write.
The confusion is understandable: fetch a product from Meta's Graph API and the group comes back as retailer_product_group_id, so it looks like the name to use when sending one. It isn't. Below is what each of Meta's references says, and what to put in a feed or a batch request.
Two names for one group
Meta's catalog reference describes item_group_id as the field that “allows you to set up variants of the same product”: enter the same group ID for all variants of one product, up to 100 characters (catalog fields reference). The same reference, in its notes for Advantage+ catalog ads, says Facebook “maps this to the retailer_product_group_id once we get your feed”. So the group you send as item_group_id is stored as retailer_product_group_id — one value, two names, and only one of them is for sending.
In a feed file
Meta's own example feeds carry the column as item_group_id in CSV and as <g:item_group_id> in XML, with the same value on every variant row and a different id on each (example feeds in the catalog reference). A Google Shopping feed already uses that name, which is why a Google-format feed imported into Commerce Manager groups its variants without any renaming.
In the items_batch API
For item_type=PRODUCT_ITEM, the batch reference lists item_group_id among the supported fields, described as “the advertiser-supplied ID of a product group; not the FBID” (catalog batch API reference). Each record's data is a map of catalog item field names to values, and retailer_product_group_id is not one of the fields documented there. Send the group as item_group_id in data, on create and on update alike.
In the Graph API product object
On the product item itself, retailer_product_group_id appears among the fields you can read, and not among the parameters for creating or updating a product (product item reference). That is the place it belongs in your code: reading which group a product ended up in, to check the grouping took.
What the group does in ads
With Advantage+ catalog ads, Meta picks only one item out of each group, based on the signal from your pixel or app event (catalog reference). A group ID that is missing, or different on each variant, leaves every size and colour competing as a separate product; the same ID on unrelated products merges them into one. Two issues in Commerce Manager come from getting it wrong the other way round: ID conflicts with group ID, when a product's own id equals a group ID, and IDs can't be duplicated, when two variants share an id.
Where FeedRobin fits
The Meta feed FeedRobin builds writes item_group_id on every variant, with the parent product's ID as the group and each variant's own ID as its id, so grouping works without a batch call of your own. The free feed check reports variants that share a product but carry no group ID in any feed you give it. For WooCommerce stores the same grouping is covered in variable products on Google Shopping.
Sources
Meta for Developers: the catalog fields reference (item_group_id, its mapping to retailer_product_group_id, example feeds, Advantage+ catalog ads), the catalog batch API reference (items_batch, PRODUCT_ITEM fields) and the product item reference (fields read and parameters written).