API: Ability to Get Field Names rather than ID's
T
Tim Dean
When I am using the API to pull data from my solution's tables, it appears that all of the fields I've added to the table are available, but instead of field names it references them using an abstract ID.
Airtable has a similar set of APIs, but theirs allows the API client to key either by ID or by name. That makes their API a little easier to use.
Jon Darbyshire
Hey Tim Dean, thanks for your feedback! Following up on this:
- Can you provide examples of specific scenarios where having field names instead of IDs would improve your workflow?
- Are there any specific field names you are having trouble with or is this a general issue?
- How often do you encounter this issue and how does it impact your usage of our API?
T
Tim Dean
Jon Darbyshire Hello Jon,
I'll answer your questions in reverse order.
* I can't answer how often we encounter because we're still evaluating SmartSuite as a platform, and it isn't clear exactly what use cases we might choose to use SmartSuite for.
* This is a general problem with all fields that are custom rather than built-in fields. It seems like the API has used IDs to avoid challenges if/when fields are renamed, which I get. But in reality we are likely to settle our field names first and then add API-based automation only AFTER the tables and fields were stable. Protecting us from field renames does little to nothing for us and our likely use cases.
My general workflow would involve calling the SmartSuite API from an event-triggered Azure Logic App or Azure Function. It would be triggered by an event saying something like "Set the 'field1' field to a value of 'value1' and the 'field2' field to a value of 'value2'. The current SmartSuite API would need me to send a PUT or PATCH request that includes 'value1' with a key that is <field1_id> and 'value2' with a key that is <field2_id>.
The question is how my Azure function/logic app KNOWS the field IDs for field 1 and field 2. There are a couple ways I can do this:
1) Get the field IDs from the SmartSuite portal, and then hard-code those IDs into my Azure code.
2) With each event, first make a call to the SmartSuite API to get the list fields and extract the proper ID value for each field I want to set. Then make the actual call to create/update the record.
3) Set up some kind of offline file that maps field names to IDs, and have my functions use that file as a map to look up the field IDs to use.
Option 1 is probably what I'd end up doing, but it makes the code less maintainable and it would likely be harder to manage things like CI/CD of my code across environments, where (perhaps)? ID values might be different across production, sandbox, and/or other environments.
Option 2 is flexible but suffers from performance degradation if it always has to make 2 API calls instead of 1.
Option 3 is possible but adds a layer of complexity that needs to managed. In a world of stateless Azure functions making that mapping file/structure readily available to a function instances could be non-trivial.
T
Tim Dean
Jon Darbyshire As a comparison point, looking at the API style implemented by Airtable works a little better for us. It allows table fields to be referenced by name OR by id.
G
Grant Beckmann
Jon Darbyshire I want to second this request and also provide my own answers to your questions.
I am just starting to start trying to build on the Smartsuite api. It's not easy. What was easy in airtable via make api...
AND(
{smartlead_email_id} != "",
{Removed from Smartlead} = 0,
{Cancellation Date} = BLANK()
)
...is not easy in smartsuite, unless using the native smartsuite integration - which is limited to 200 records for lookup, which is a drastic limiter of effectiveness.
To filter these same results I could easily get in airtable, I have to do something like this...
{ "operator": "and",
"fields":
[
{ "comparison": "comparison_name", "field": "field_slug", "value": any },
{ "comparison": "comparison_name", "field": "field_slug", "value": any }
{ "comparison": "comparison_name", "field": "field_slug", "value": any } ] }
Then I have to go manually lookup what ever single one of the slugs is - for every single step I build in the automation. When updating a record that has dozens of fields, this requires me to go back and look up every single slug that I'm trying to fill. When getting records back from a lookup that I want to send to other places, I have to guess, based on the contents of the return, which slug goes in which direction. That is not feasible to do at scale or efficiently at any level.
As I mentioned in another post, the current api is almost unusable to build on efficiently because of this issue. I would love to use the native integration in make as an alternative, but again, this is limited to 200 records lookup at a time, with no option for an offset. Therefore, this requires me to iterate through a lot of linked items to get all of the records I need to, rather than looking up all the records at once.
Would love to see improvements to the API. Smartsuite is leading the way above Airtable in so many ways, but in this, it is missing the mark.