I’m working with the Notion API to create databases with relation properties. When I set up a new database and define a relation using the dual_property option, Notion automatically creates a field on the target database with a name like “Related to DatabaseName (FieldName)”.
The problem is that I want to control what this related field is called from the start. Right now I have to create the relation first, then make another API call to rename the auto-generated field. This means I need two separate requests and extra logic to handle the renaming process.
Has anyone found a way to specify the synced_property_name parameter when initially creating the relation? I’m hoping there’s a property I can include in the database creation request that lets me define the custom name for the reverse relation field upfront.
This would save me from having to do the create-then-rename workflow every time I set up bidirectional relations between databases.
Yep, this limitation is still there in the current API. Hit the same wall building a CRM that needed clean relation names between contacts and companies. The docs don’t mention it clearly, but synced_property_name only works on updates, not when you’re creating relations. Here’s what worked for me: batch everything. Create all your relations first, then run a second batch to update the names. Way less back-and-forth than doing them individually. Just make sure you track which relations got created so you can reference them properly in the updates.
Had the exact same frustration building client integrations. There’s no way to set the synced property name when you first create the relation - the API just doesn’t support it. You’re stuck with that annoying two-step process. Here’s what helped me: batch everything if you’re creating multiple relations. Fire off all the creation requests first, then hit them with the rename operations right after. Just make sure you’ve got solid error handling because step two can bomb if step one hasn’t finished processing. I throw in a small delay between steps to avoid timing issues. Makes it way more reliable, though it’s still pretty inefficient overall.
yeah, still broken as of last month when I was buildin database templates. Notion forces ya into that create-then-update pattern which sucks for automation scripts. I just accepted the extra API calls since there’s literally no other way around it.
totally feel ya! It’s a pain having to rename after creation. I wish nothin could just let us set the names right off th bat. let’s hope for an update soon so we don’t have to deal with this hassle!
unfortunatly this limitation still exists in the current API version. I’ve been wrestling with this exact issue for months and there’s no workaround except the create-rename approach you mentioned. Really hope Notion fixes this soon cause it’s annoying havin to make extra calls.
Nope, the Notion API won’t let you set a custom synced_property_name when you first create a relation. I hit this same wall building a database migration tool last year - had to use the exact two-step process you’re dealing with. You can only use synced_property_name when updating an existing relation, not creating one. Seems like Notion wants the reverse relation created first before you can customize it. I wrapped both steps in one function to keep things cleaner - create the relation, immediately update it with the synced_property_name I want, then handle errors from both steps together. Not perfect, but way easier when you’re doing this a lot.
Had this exact problem building a project management system with multiple databases. The Notion API won’t let you set synced_property_name when you first create a relation through the database properties endpoint. It only works when updating existing relations that are already set up. I ended up writing a helper function that does it in two steps - creates the relation first, then immediately updates it with the name I want. Not great for performance, but it handles the messy workflow automatically so I don’t have to deal with it every time. The function waits for the initial creation to finish before trying to rename, otherwise you’ll hit race conditions.